LPC4350 IAR and J-Trace Cortex M

[lpcware]

Content originally posted in LPCWare by gregd on Tue Jul 31 20:03:47 MST 2012
I am using the Hitex LPC4350 Rev A4 evaluation board along with the Segger J-Trace Cortex M with the IAR EWARM v6.40.1.3812. I am running J-Link DLL v4.50m and J-Trace Cortex-M Rev.3 firmware.

I have been using this setup for several months. At first everything seemed to work very reliably. As my project got larger, I have started having problems downloading the images to the board. I have tried two different Hitex boards with the same results. The same issue seems to occur with a standard J-Link ARM debugger as well. I am storing the program in the external NOR flash on the board when debugging and I have “verify download” enabled. I am using the latest version of the Hitex NOR flash program that came with the lpc43xx.git project (LPC43xx CMSIS driver library) from the sw.lpcware.com website. I have also tried the flash program included with IAR with the same results.

Basically, what seems to be occurring is that 99% of the time, the first download/debug attempt fails with the results shown in the attached file. The second attempt always works 99.9999% of the time with no errors. If you simply hit the debug tool bar button over and over without recompiling, it seems to be successful only every other time very repeatedly.

In the attached file, I have included the debug log and flash0.trace file, and IAR J-Link configuration dialog boxes for your review.

Anyone have any suggestions? This issue eventually starts to waste a lot of time.

Thanks,
Greg Dunn
304-542-4383

Original Attachment has been moved to: LPC4350%20Download%20Problems.zip

[lpcware]

Content originally posted in LPCWare by david_sh on Mon Aug 13 05:32:13 MST 2012
I have met the same issue,  try some ways for two days, but no effect, maybe we have to change to keil MDK?

[lpcware]

Content originally posted in LPCWare by gregd on Thu Aug 02 05:34:47 MST 2012
I think I may have finally figured out the issue on my own.  It has to do with the M0 core being allowed to run at some point during the flashing process.  In my case the M0 application was writing data to the portion of internal ram where the flashing buffer was located.  The data was apparently being changed between the time that it was written to the buffer and before the flashing algorithm wrote it to flash.  This would cause the verification step to fail.  To fix the problem, I updated the the icf file used by the flashing algorithm project on the following entries:

define symbol __ICFEDIT_intvec_start__ = 0x2000C000;
define symbol __ICFEDIT_region_RAM_start__ = 0x2000C040;
define symbol __ICFEDIT_region_RAM_end__   = 0x2000FFFF;

This moves the location of the flashing code and buffer to a memory location which is not currently used by either my M4 or M0 application.  This area of memory can be configured for use as the Embedded Trace Buffer but appears to be disabled by default during reset.  I am not currently using the ETM portion of the internal ram (0x2000C000 to 0x2000FFF) in my application so this will probably work for now.  As my application continues to grow, I may start using this memory area however.  A more general purpose solution would be to make sure that the M0 cannot run during the flashing process.  I also tried to update the flashing macro code to add a dummy loop for the M0 to run as I have seen in other example macros:

  // Load loop code so M0 simply loops without executing any damaging code
  __writeMemory32(0x00001F00,0x10080000,"Memory");   /* dummy stack pointer */
  __writeMemory32(0x000000D5,0x10080004,"Memory");   /* reset handler */
  __writeMemory32(0xE7FEE7FE,0x100800D4,"Memory");   /* jump to itself instruction for M0a */
  __writeMemory32(0x10080000,0x40043404,"Memory");   /* M0 shadow pointer. */

This didn't seem to help the problem however.  It must be because the M4 code copies the M0 application code from external flash to internal RAM for execution during reset.  Maybe the M4 is allowed to run at some point during the flash process also, or maybe I needed to reset the M0 in the macro as well.  Anyway, I could not find a solution that will work in all cases.  If someone knows the internals of how everything works they may be able to suggest a solution that will work even if the M0 application uses the entire internal ram space.

Thanks,
Greg Dunn