MSP432P4111: Jumping to different Application software in flash takes a long time

Hi Casper,

This is a good one.  Let me dig into this and come back with some suggestions.

@Dennis, did you find some possible solution to the issue? We are currently using the SDK v3.20 because of an issue with using the CRC32 module in C++ but it seems the issue pops up in the later versions as well. Because of our application (and the impossibility to re-program an eventually bricked MSP in the field), we keep multiple images in FLASH with one of them that cannot be erased (to guarantee at least a basic functionality). This makes it quite different from other implementations we have seen online and, unfortunately, I haven't found any other workaround to this bug...

Hi Stefano,

I'm trying to find one of the other engineers that has experience with this type of "hopping" to different entry points.

Hi Stefano,

It's hard to say what could be causing this issue, but here are a few suggestions:

• Is your watchdog enabled? Can you try holding the watchdog during cinit auto-initialization. There is an option in CCS (--cinit_hold_wdt)
• Do you have MPU enabled for both P401 and P4111? Can you try disabling it?
  
• Can you try debugging _c_int00?
  Can you single-step to check where the code is getting stuck?
  Another option is to modify this function. The source code is located in:

             {CCS}\ccs\tools\compiler\ti-cgt-arm_20.2.0.LTS\lib\src\boot_cortex_m.c

     I think you can drag-and-drop this function to your project and you can override the one from the default library.

You could try placing some GPIO toggles or something to check where the code is getting stuck. It seems to me like the code is going to __TI_auto_init and something might be happening there.

Regards,

Luis R

Thanks Luis for the pointer. We will look into the source code to see if we can spot where things go wrong.

We currently have an external watchdog (and so we cannot halt it). We now extended it to its maximum (~25s) but still it trips. We are currently creating images that only differ from each other for the entry point (to basically fit them in different FLASH locations) and the initialization time is directly proportional to the code size, meaning if the new image is only few kilobytes, this process lasts 1-2 seconds. But if we create an image of 100-200kbytes we exceed the 25s for booting, suggesting there is some kind of loop in there that goes wrong.

Stefano

We debugged the code a bit further and landed in copy_zero_init.c, specifically in __TI_zero_init_template().

The part where we get stuck is here:

      if (USE_MEMSET)
         memset((void*)outbuf, 0, count);
      else
         while(count--) WRITE8_ADV(outbuf, 0);

and we tried with both USE_MEMSET to 0 and 1. In both cases, we see that the memset or the while(count--) takes a huge amount of time to complete (20-30s) when we operate with the "over-the-air" updated firmware and less than 10ms with a normal boot. We even tried to write our own piece of code to initialize the SRAM (a for loop) and we noticed it also takes ages to execute. What seems to be happening here is that all SRAM access is very slow. We also checked the memset parameters and they are always the same so it seems really SRAM access time is the difference.

If we comment out the memset and the while(count--), we go very fast to through the initialisation code but as soon as we reach the constructors of the different objects in main, in case they also have a memset in their code, the problem is the same (going through the memset takes a lot of time, 10s of seconds). Every memory initialization we are executing is very slow.

But, inside the main, if we are reading/writing in SRAM, it is very fast again. I am not sure if this is related to the MMU as, even disabling it did not make a difference. What could be the reason for the SRAM access to slow down so much?

Hi Stefano,

It's been a few days since I have heard from you. Were you able to figure out what is happening?

We parked the issue for a while but, yes, we still have the same problem. It seems that writing to SRAM can be made slower somehow: we think this might have to do with wrong settings on the MPU. Inside the main() code, SRAM access is always fast but before going into main (basically the code from the address pointed by the reset vector to the beginning of main) access to the SRAM is very very slow. This is only the case when we change the default reset vector location. Stepping through simple variable assignments or loops becomes very slow but, as soon as we go inside the main function this becomes fast again.

We plan to take another look at the code (especially because in ~2 months we will need to have sorted this issue out).

Stefano