• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 81 subscribers
  • Views 228 views
  • Users 0 members are here
Support feedback
Options
Options

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Reprogramming flash memory with updated application program FYI

Pat Harris
Genius 3890 points

Santosh,

Thanks for your assistance Friday. It allowed me to continue debugging my application that overlays the current program with an updated version.

Since Friday, I have found a couple additional quirks that I had to implement in order to get my application fully operational.

Reference for earlier changes to the example flash_prog:

http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/310667/1087302.aspx#1087302

 

here's the list of the latest changes required:

Place the stack RAM in a seperate location from the heap memory (for RTOS).

Place all functions in Fapi_UserDefinedFunctions.c in ramfuncs

Remove all calls to WDT and disable WDT before replacing the lower flash code

Place the following code in the ResetISR function

 // Jump to the CCS C Initialization Routine.

__asm(" movw r0, #0x4bfc");


__asm(" movt r0, #0x2000");

__asm(" mov sp, r0");

__asm("    .global _c_int00\n"

 "    b.w     _c_int00");

and new changes - these may be compiler issues. I am using TI v4.9.7.

The flash programming tool would not program .cinit and .const when they were attached at the end of .text. I had to assign specific locations for the programming tool to be effective. I would get status error 509 telling me that there was a buffer length or bank limit problem. Both errors seemed bogus, so I tried the alignment and my test example was stored properly. But my larger application .text which spanned several sectors then also had a problem with sectors M and L, so I assigned all .text to start at sector J and then it worked.

Perhaps Someone at TI could explain if this is a compiler problem?

Again, thanks Santosh. Sometimes these problems can be resolved with a short dedicated interaction such as I received with Santosh. To me, this makes so much more sense that having to hunt and peck through all the posts, rarely finding any specific reference to the problem. Talking with someone who really knows the hardware as well as the software tools has been immensely more cost-effective for me and I suspect for numerous other users.

I would have gladly paid a support fee knowing that I would have someone who would stick with the problem until it is solved. I would like to strongly encourage TI to consider this as a more viable option for their business.

I have attached the latest .cmd file

0815.F28M35H52C1_m3_FreeRTOS.zip

Pat