• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 154 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LC4357-EP: Flash or ECC or unknown root cause

Spencer Durrant
Prodigy 70 points

Part Number: TMS570LC4357-EP

I have encountered some bug while developing a bootloader. After writing all data to the flash I run a CRC32. But it seems that the first chunk (sixteen 32-bit values) is not updated unless I run the crc32 first but this is too late and results in the wrong crc. If I insert the crc32 twice, the first call gets the flash addresses update and I get the correct crc value from the second call. The application runs perfectly if I jump to it so I know it gets written to flash correctly. I tried running a loop (shown below) and this did work too.

I also noticed section 4.4.9 in the f021 flash API and called the Fapi_flushPipeline() and that didn't affect anything. I also observed the note there to try 2 dummy reads 128 bytes apart from the flash addresses I modified - didn't solve anything either. 

I also confirmed that running the code without the debugger resulted in the exact same behavior. So it seems that running the crc32 twice or running the dummy read loop can work but this is just covering the issue.

Any suggestions? Is this a known thing? Is this an ECC, flash, or cache problem?

Shown below are screenshots of how it looks before running a crc32/loop and after.

Before:

After:post-app-load.png


// This code inserted before the crc32 did seem to resolve the issue too    
volatile uint64_t warmup = 0ULL; // ECC warmup variable
for(uint32_t addr = VALID_APP_FLASH_BASE;
    addr < VALID_APP_FLASH_BASE + APP_FLASH_SIZE_WORDS;
    addr += 8)
{
    warmup = *(volatile uint64_t*)addr;
}
  • 0
    Prodigy 70 points

    An update on this,
    I updated the code to exclusively use the flash API for reading the data in the crc32 function. This did not resolve the issues I'm seeing.

    The warmup loop was actually an inconsistent workaround to resolve the issue. But running the crc32 twice remained consistent to get the flash values to update - seems like it needs to run with a length of about 128KB to get the values to update consistently.

    When running the debugger while flashing my application and setting the memory window to continuous refresh - I do see the correct values occasionally showing up. But when it reaches the point to run the (first) crc32 it always pauses with the values shown in the first image above. Again, running without a debugger attached shows similar behavior.

    Still unsure what the reason for these flash values to update for reading properly is. Any suggestions or information would be helpful.

  • 0 in reply to Spencer Durrant
    TI__Guru* 77636 points

    Hi Spencer,

    unfortunately, i never came across this behavior before.

    1. Could you please try to disable cache once on bootloader code and do the testing once:

    And also, i need clarifications on below things:

    1. Which bootloader you are using?

    2. Which CRC are you using Hardware or Software?

    3. As per my understanding of your project, first your bootloader project will receive application over one communication medium and then it will write the corresponding application into flash using FAPI library. Once application written into flash properly then you are computing CRC for your application. Is my understanding being correct?

    4. What are you planning to do with the generated CRC? Is there any pre calculated CRC also there in flash along with application? Do you want to compare this with that?

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 70 points

    Hi Jagadish,

    1. To answer the cache question, there is a second problem I believe is related. When I restart the device and have a good application flashed, I run a CRC and compare to what I have saved in flash. However, once I reach the point in code where I would run the CRC the 2nd 32-bit word always changes - completely randomly within the function shown in the image below - and the CRC does not match what I save in flash (once again the first time only). This is consistent with and without the debugger.

    Now, if I run the warmup loop shown below, sometimes this causes the single word to correct - but not always. 

    If I disable the cache, this does consistently work without a warmup loop or two crc32() calls. However, my code is safety critical and I can't use compiler optimizations -> results in my code requires the cache everywhere else or the program can't communicate properly - my Bootloader is CPU only, no interrupts or DMA to reduce large testing efforts. I've tried disabling cache -> running CRC -> re-enabling cache -> and invalidating cache in the image below but the MCU keeps crashing somewhere. 

    Last note on this, if I keep cache disabled I can't communicate correctly to receive the application to write into flash. 

    1. I am using a custom bootloader. I can provide some parts of my flash driver code using the Fapi if that is useful.

    2. I am currently using software CRC. I would like to switch to hardware CRC, do you have an example of code using it on this device?

    3. Yes I receive the application over the SCI, I copy it into 8-byte aligned memory buffers, and write to flash in small chunks. I've been using both 32-byte write sizes and 8-byte write sizes with Fapi_issueProgrammingCommand(). And yes once the application is written into flash, the TMS570 receives a CRC from the external device (a PC) sending the application binary, then I run the crc32() as shown in the first post on this page which I use to compare with the CRC the TMS570 just received from the PC.

    Regarding my original post, after running crc32() once the flash values are corrected but the result is a mismatched CRC -> after running crc32() a second time the result is a matching CRC (and the flash values don't change again).

    4. Once the CRC is generated and matches the CRC received from the PC, I save this into flash in Bank 7. Then I use this correct, saved CRC upon restart/reboot to compare to another generated CRC -> the image in this reply is my code at restart to run a CRC on the application to verify it is uncorrupted. Now, as I explained in the first part of this reply, the CRC match would fail without the loop or running crc32 twice. 

    Finally, I believe the CRC generation and logic itself is no issue and is correct, and that I do write to flash with API correctly. I'm still quite lost on what else I can try or look into

  • 0 in reply to Spencer Durrant
    TI__Guru* 77636 points

    Hi Spencer,

    My sincere apologies for the delayed response!

    I never experienced this issue on this device. To proceed further on this issue i need two things from your end.

    1. Could you please setup one live debugging session with you.

    2. And then if required i need your code or any demo code with this example.

    I will be available between 10AM to 10PM IST. You can schedule a call based on your availability. Note: Tomorrow (Friday) is holiday for us.

    --
    Thanks & regards,
    Jagadish.