LPC2478 only runs when code flashed via JTAG - not via FM

Started by crossing, February 27, 2010, 12:52:14 PM

Previous topic - Next topic

crossing

Dear Andy, dear friends ,
the problem occurs on a new developed board. It is the 2nd board we developed with LPC2478, on the 1st one the effect was unknown.

Now let me describe the problem:
Firmware runs fine when downloading with Tantino JTAG Debugger under Hitex IDE. It remains and runs without Tantino, too.

Now I download the ihex file with FM in ISP mode. Verify ok.
But doesn't start!

So I checked the quartz: No oscillation. Obviously firmware doesn't initialize the clk-registers.

I checked the hexfile: looks fine up to 0x4C and above (where the inits begin) and the code looks exactly the same as in the IDE.
I double checked with the binary I obtained when running objcopy with binary option.
Finally I'm sure the elf-, the ihex- and the bin-files are o.k.

But when I display (read back) the code from flash, I see differences, many 00.

The code for the 1st board was pretty smaller. So I suspected the size as a problem.
I loaded it (for it was a running code) and - it started the quartz.
Next I manipulated the ihex file to get a shorter code - guess what? Quartz started.

I load the original ihex - same problem as in the beginning.

When programming with FM the counter starts at 7xxxx..something I can't fix because it counts down to fast. (Is it 7CFFF???)

Does FM check file size/flash overflows? I suspect there may be my problem.

Best regards
Andreas



Andy Ayre

Flash Magic programs the flash backwards, because the first 512 bytes contains the checksum at location 14H and it is this checksum that allows the bootloader to execute the code. So by programming the first 512 bytes in memory last it stops partially programmed code from being executed.

Have you checked the hardware is not causing the device to stay in the bootloader on every reset?

After programming with JTAG what happens if you reset the hardware by removing power, disconnecting JTAG, applying power? Does your firmware run?

You say the verify in Flash Magic passes but you see differences. What are you comparing it to? You can use File -> Save in Flash Magic to save a hex file from the device - that might help.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

crossing

Dear Andy,
here come the answers to your questions:

>Have you checked the hardware is not causing the device to stay in the bootloader on every reset?
Seems to be fine, RESET is H =  inactive and EINT0 is H =  inactive, too.
FM does start the programming after pulling down these in the correct sequence.

>After programming with JTAG what happens if you reset the hardware by removing power, disconnecting >JTAG, applying power? Does your firmware run?
Yes, firmware runs as expected after reset and/or power on. That's the way I can display the flash content later with FM.

>You say the verify in Flash Magic passes but you see differences. What are you comparing it to? You
can >use File -> Save in Flash Magic to save a hex file from the device - that might help.
I read and compare bytewise the machine code. Its the same in the disassembly window of the Hitex IDE and in the hex file and in the binary when flashed via JTAG.
It's actually mostly 00, on >14h i have FF FE FF FF  when flashed via UART0.


Andy Ayre

Are the memory differences always at the same locations? If so view the contents of Flash in Flash Magic and check those locations.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

crossing

I think I figured out what the reasons were:
The built hex file contained one area, where the address range from 8000.0000 to 80001AF0 was filled with data (before optimization with 00).
However, >8000.0000 is reserved for external RAM!
Deleting this part from hexfile made the firmware run.
We will now check the obj files etc. to avoid effects like that further.
Nevertheless, Flash Magic obviously doesn't check the allowed memory range and overwrote with the data, respectively Zeros.

Thank you for your help

Andy Ayre

Depending on your version of Flash Magic it used to be that older Keil compilers located data in that range that was meant for another memory area. Therefore Flash Magic tried to accommodate those hex files.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com