Sign in

Search 68hc12

Subscribe to 68hc12

68hc12 by Keywords

68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Discussion Groups

Discussion Groups | 68HC12 | RE: Problems programming flash on M68KIT912DP256 with BD M Multilink/Metrowerks

Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).

RE: Problems programming flash on M68KIT912DP256 with BD M Multilink/Metrowerks - Kellogg Dave - Aug 30 10:23:00 2002

I am also using the P&E MultiLink, but with the Cosmic tools. I have found that the MultiLink works best if plugged directly to the parallel port on the PC, with no DB25 cable. Even cables marked "IEEE-1284 compliant" are not reliable. On one day it will work, on the next it won't. To gain distance between the PC and the target board, I replaced the 18" long 6-pin cable with one that I fabricated from Cat-5E cable with 6-pin connectors on both ends. In the Cat-5E cable, there are 4 twisted pairs. I commoned one of the lines in each pair (4 total), and connected to ground. Of the remaining 4 lines, I used one for BGND, one for RESET, and two for +5v. I have successfully (i.e., it seems to work) used a cable of this construction that is 15 feet long. Typically we use a cable that is about 5 feet. When I get a chance, I want to try a really long cable (50 feet?), just to determine a threshold of confidence. This might not be the cause of your problems, but it might help. 607-656-2597 -----Original Message----- From: djsimpson100 [mailto:] Sent: Friday, August 30, 2002 8:23 AM To: Subject: [68HC12] Problems programing flash on M68KIT912DP256 with BDM Multilink/Metrowerks Hi all, I am having problems programming the flash on the MC9S912DP256. I am using Codewarrior HC12 V1.2 and the P&E BDM Multilink which came with the Motorola M68KIT912DP256. If I load the Fibo Flash example, the debugger stalls at at the 60% mark in executing the postload cmd file, and the code is not written to flash. This also seems to crash the BDM Multilink as I cannot write to or edit the RAM. If I load the the LEDS-EVB_DP256-RAM example, everything works fine (ie I can single step, examine/change ram etc until I access the FLASH menu item under the ICD-12 menu. When I look at the Flash, under the ICD-12 menu item, all the flash is at the same address as shown below when loading the Leds-EVB-RAM example. Name Start End State EEPROM 00000400-00000FFF Enabled/Blank/Unprotected FLASH_4000 00000400-00000FFF Enabled/Blank/Unprotected FLASH_C000 00000400-00000FFF Enabled/Blank/Unprotected FLASH_3 00000400-00000FFF Enabled/Blank/Unprotected FLASH_2 00000400-00000FFF Enabled/Blank/Unprotected FLASH_1 00000400-00000FFF Enabled/Blank/Unprotected FLASH_0 00000400-00000FFF Enabled/Blank/Unprotected If I try and do anything to the Flash I get an error message "Operation failed on FLASH_x flash module" (where x is the module I tried to program/disable/protect). Some times the addresses given in the table are different, and sometimes the MCU speed was not show correctly as 8.00 MHz. (Once was 0 MHz, and once was 49.9MHz) The BDM appears to work, as I can run / debug etc the leds-EVB-RAM example. I have tried this on two computers, both with the same result. I was then able to try a Motorola SDI pod, and with the same EVB and same computer I am able to correctly program and access the Flash. Any help would be appreciated. Thank you! David J Simpson -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: Problems programming flash on M68KIT912DP256 with BD M Multilink/Metrowerks - djsimpson100 - Sep 2 7:16:00 2002

Hi, Thanks for you help. I think the problem may even be a faulty BDM Multilink. I have tried plugging it in directly to the parallel port on three different computers (with different mother boards and operating systems) and it doesn't work on any of the them when I try to program the flash. The strange thing is that is seems to work OK for RAM only code. I can download code and execute it, single step it etc if the code is in the RAM, but as soon as I try to program / access the flash via the BDM, it doesn't work, and the BDM needs a reset. I can't belive the BDM is that tempremental that it won't work on any of my computers. I have been in contact with support europe over the last two weeks , and they have suggested several things, none of which have worked. Hopefully I will have access to an other BDM tomorrow to see if the BDM is working or not. I'm getting a bit desperate, as I have code to develop which needs to be programmed into the flash, but instead seem to be stuffing around with BDM problems. David --- In 68HC12@y..., Kellogg Dave <dave.kellogg@r...> wrote: > I am also using the P&E MultiLink, but with the Cosmic tools. > > I have found that the MultiLink works best if plugged directly to the > parallel port on the PC, with no DB25 cable. Even cables marked "IEEE-1284 > compliant" are not reliable. On one day it will work, on the next it won't. > > To gain distance between the PC and the target board, I replaced the 18" > long 6-pin cable with one that I fabricated from Cat-5E cable with 6-pin > connectors on both ends. In the Cat-5E cable, there are 4 twisted pairs. I > commoned one of the lines in each pair (4 total), and connected to ground. > Of the remaining 4 lines, I used one for BGND, one for RESET, and two for > +5v. > > I have successfully (i.e., it seems to work) used a cable of this > construction that is 15 feet long. Typically we use a cable that is about 5 > feet. When I get a chance, I want to try a really long cable (50 feet?), > just to determine a threshold of confidence. > > This might not be the cause of your problems, but it might help. > > Dave.Kellogg@R...