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.

CCS/TMS320F28035: Failing to write to 0x3F7FF6 (boot to flash entry point) via flash kernel or Code Composer/JTAG

Part Number: TMS320F28035


Tool/software: Code Composer Studio

I am having a strange issue that I just started noticing.  I have modified the f28035 flash kernel to flash an application over CAN.  The flash kernel sits in sector A of flash, and the application goes in sectors B-H.  I am usually able to flash the application via the flash kernel just fine, but every once in a while it fails when trying to the write to 0x3F7FF6, the boot to flash entry point.  Whenever I see this failure in my flash kernel, I try to flash it via Code Composer/JTAG and it fails then too.  It erases the flash sectors just fine, it even writes to every flash location (basically the entire app) until it gets to 0x3F7FF6 at the end and it fails to write to that spot.  I can program the last application that wrote to 0x3F7FF6 just fine, but I can't program a different application.  It's like the first application to write to that location locks it until I completely erase all flash sectors and then everything works again....for a while.  Is there some weird permission issue when writing to 0x3F7FF6 or something?

  • Hi Adam,

    That is indeed strange. In this condition if you connect to CCS and view the content at location 0x3F7FF6 via CCS memory view, what value you see? Also when you see this issue, are you able to erase the flash via CCS ?

    Location 0x3F7FF8 and beyond are password locations and if anything get programmed there then device get LOCK and that will prevent any further programming but I assume you are not programming those locations.

    Regards,

    Vivek Singh

  • So I have two applications that I'm using to test my flash kernel.  Let's call them A and B.  If I erase all sectors of flash, then program my flash kernel to sector A using CSS, then program app A to sectors B-H, that works fine and the content at location 0x3F7FF6 is was is supposed to be there for app A, verified by the hex file.  But then if I try to program app B to sectos B-H, it seems to fail when trying to write to 0x3F7FF6.  Everything for app B seems to write ok until it gets to that location.  The content at 0x3F7FF6 remains what it was when I programmed app A.  But this doesn't happen all the time, I don't think.  It's like app A can write to that location just fine, whether programming via my flash kernel or CSS, but then when I try to program app B, and it tries to write to 0x3F7FF6, it fails.  If I erase all flash sectors, then everything works ok again and I can flash app B or app A just fine.  But then it will eventually fail again.

    If I set up my target configuration file to erase all sectors of flash, I can program whichever app I want anytime, but then I obviously overwrite my flash kernel in sector A, which I don't want to do.

    I just took a look at my linker file and there is a section in there for 0x3F7FF8, though I'm not sure it's being used.  I have to do more investigation tomorrow.  I'm not sure why it works sometimes, but not other times.

    Can you explain to me a bit more how those password locations work?

  • I figured it out. I had my flash kernel sitting in sector A. So of course before I begin the process of writing my application to sectors B - H, I have to erase those sectors, but I don't erase sector A. I want the device to boot to my application on startup, so I need the write process to be able to write to the boot to flash entry point (0x3F7FF6), but that location belongs to and is erased with sector A. But I can't erase sector A because that's where my flash kernel is. So when the application write process tries to write to the boot to flash entry point, it fails because it wasn't previously erased.

    The solution was to move the flash kernel to sector H and the application to sectors A - G. Now the flash kernel can freely erase sector A (and hence the boot to flash entry point) and then write the application and the boot to flash entry point without issue.

  • Adam,

    Good to know you could find the issue and thank you for posting the finding.

    Vivek Singh