RM48L952: RM48 AC (Power) brownout interrupts during TI Bootloader init corrupts flash, but not with HalCoGen generated init of board

Hello Tammy,

When you state that the bootloader loafs the Halcogen code, can you describe how it is loading it? i.e., your description sounds as if the bootloader programs the code into the device flash on every startup with the bootloader. is this correct?

If this is the case, you need to insure that the voltage is stable during this time. The sw has no way to know if there is sufficient capacity of the supply to program the flash and a dip in voltage will cause invalidly programmed bits. The only ways I am aware of to resolve this is to include a power reserve and/or external voltage supervisor. The power reserve could be something such as a super cap or battery supply in the hardware that can "take over" when the voltage dips below the device minimums or approaches the device minimums. The voltage monitor could be used to determine the threshold where the the supply transitions to the reserve or it could be used to indicate to pull reset on the MCU when power dips. If it pulls reset, there is also a risk that a write operation is ongoing and could corrupt data, but the next boot up will then allow reprogramming if the first did not complete properly.

If you were to try to do something in SW, it would have to be something related to monitoring the supply voltage using the ADC. The challenge here is if the reference voltage for the ADC were also compromised you may see a proportional change in the volts per ADC count that masks the issue. The other method would be to use the external Voltage supervisor to signal the MCU when power is nearing a trip point well within the limits of operating voltage limits so the MCU would have time to gracefully shut down and protect the flash memory from corruption. This, of course would mean that the transitions of the voltage would have to be dampened enough to allow time for the detection, notification, and reaction.

Hi Chuck,

  Thank you for your time.

Q1. When you state that the bootloader loafs the Halcogen code, can you describe how it is loading it?

No the halcogen based application code is already in Flash. The bootloader is at 0x00000000 and the halcogen based code is located in a different part of flash. Do you want me to upload the TI bootloader version we downloaded and are using? The TI bootloader we downloaded and using does the basic board bring up then jumps to another location in flash to load the halgocgen generated code with our app that is compiled in code composer to be bootloader supported (the bootloader project is seperate in code composer). If someone has a problem with unstabe AC, and it happens when the bootloader is running that is when flash is corrupted. if something happens to AC after the bootloader has loaded the halcogen based application is executing there are no problems as well as if we run halcogen based applications on board with no bootloader (debug version on code composer). But if it is during when the bootloader is running, the RM48 flash is corrupted. hat is why I asked what we could make identical in the TI bootloader initialization code as the HalCoGen generated initialization code so the bootloader behaves the same as the halcogen code.

Q2. If this is the case, you need to insure that the voltage is stable during this time.

We cannot control the customer sites in terms of their issues with power, old buildings and wiring, etc. that they are plugging the RM48 board into

With the options you describe above, is this what the HalCoGen code is doing, and that is why there is no problem with this code when the AC is unstable? Can we make those changes in the TI bootloader so the bootloader behaves the same way? Which registers did HalCoGen set that protects against this? I can upload both the TI bootloader and the TI halcogen autogenerated code so you can see the difference.  Thank you again.

Tammy,

The MCU runs on DC. The AC has to go through some sort of inverter/regulator. This is a system issue. It is something that should be accounted for during system design by using a regulator that can filter AC dips or adding some sort of power reserve to prevent brownout where we are defining brownouts as points where the supply voltages to the MCU fall outside of the specified voltage minimum and maximum. Operation of the device when the supply voltages are outside of the specified limits is indeterminate. What is most likely happening, is when the brownouts occur during operation of the boot loader, the CPU jumps to somewhere in the code that is performing flash writing (i.e., somewhere in the Flash API) which results in the flash corruption. Assuming your application/Halcogen generated code does not incorporate the Flash API or at least that the application size is much larger, it is less likely that that the code jumps to a portion of code that access flash operations.

The only other potential thing to do to protect operation would be to use the MPU or some other protection mechanism to prevent access to the flash api code by parts of the code that doesn't have permission to do so. If you are using SafeRTOS, this might have some capability for that. This may or may not help. The reason for the uncertainty is as stated above that the CPU operation when outside of the specified voltage range is indeterminate so we can't really provide any assurance that the CPU or RTOS will operate as expected.

Really, the best method to prevent these brownouts, is to accommodate the condition in HW as I have mentioned previously.

Hi Chuck,

  Thank you. The engineering team wanted me to provide you the attachments. Please see attached uploads, the TI bootloader  which has this problem when AC is unstable, and the HalCoGen code that is Ok when AC is unstable. That way you can see how different the initialization code is in both. We grep'd through the bootloader code but did not see where it is writing to Flash. When it is running for us, it should only be jumping to another location in flash where our app code is located and loading that into RAM and executing. If there is code in the TI bootloader that is writing to flash and is the root cause of this problem, where can we locate it because we want to remove if (but I could not find it). But you have both the halcogen generated init code and the TI bootloader so you can see what I meant. Thank you again.

2553.HalCoGen (2).zip

6557.boot_sdcard.zip

Thank You,

Tammy

Hi Chuck, We reversed engineered and did a diff between the HalCoGen init code and the bootloader init code. Some of the differences included:

1.In function _c_int00:

1.1 _coreInitRegisters_(); #31 not initialized in halcogen version and #19 not initialized in bootloader version

1.2 _coreInitStackPointer_(); ** different in both versions, #31 and memory alloc

1.3 _coreEnableEventBusExport_(); missing in bootloader version

1.4 _coreEnableFlashEcc_(); missing in bootloader version

1.5 _errata_CORTEXR4_66_(); missing in bootloader version but there is no source code to copy, what library is it in?

1.6 _errata_CORTEXR4_57_(); missing in bootloader version but there is no source code to copy, what library is it in?

1.7 not in bootloader version. if ((esmREG->SR1[2]) != 0U) { for(;;) { }/* Wait */

2.In function systemInit, muxInit is missing from the bootloader version

3. In function setupPll: systemREG1->PLLCTL1 set differently = 0x00000000U | 0x20000000U | ((0x1F)<< 24U) | 0x00000000U | ((6U - 1U)<< 16U) | ((120U - 1U)<< 8U); / /** set to 150U in HalCoGen version

4. In function setupFlash: flashWREG->FBFALLBACK is set differently. In bootloader version = 0x00000000 | (SYS_ACTIVE << 14U) | (SYS_SLEEP << 12U) | (SYS_SLEEP << 10U) | (SYS_SLEEP << 8U)

| (SYS_SLEEP<< 6U) | (SYS_SLEEP << 4U) | (SYS_ACTIVE<< 2U) | SYS_ACTIVE;

in HalCoGen version = 0x00000000U | (uint32)((uint32)SYS_ACTIVE << 14U) /* BANK 7 */ | (uint32)((uint32)SYS_ACTIVE << 2U) /* BANK 1 */ | (uint32)((uint32)SYS_ACTIVE << 0U); /* BANK 0 */


5. In function trimPLO: bootloader version set differently systemREG1->LPOMONCTL = (1U << 24U) | (16U << 8U) | 8U; //halcogen version it is set to 16U


6. In function mapClocks:

6.1 systemREG1->CDDIS set differently in bootloader version = (FALSE << 4 ) /* AVCLK 1 OFF */ |(TRUE << 5 ) /* AVCLK 2 OFF */ |(FALSE << 8 ) /* VCLK3 OFF */ |(FALSE << 10) /* AVCLK 3 OFF */ |(FALSE << 11); /* AVCLK 4 OFF */

in HalCoGen version = (uint32)((uint32)0U << 4U ) /* AVCLK 1 OFF */ | (uint32)((uint32)1U << 5U ) /* AVCLK 2 OFF */ | (uint32)((uint32)0U << 8U ) /* VCLK3 OFF */ | (uint32)((uint32)0U << 9U ) /* VCLK4 OFF */
| (uint32)((uint32)0U << 10U) /* AVCLK 3 OFF */ | (uint32)((uint32)0U << 11U); /* AVCLK 4 OFF */

6.2 setting systemREG1->PLLCTL2 and systemREG1->CLKCNTL missing in bootloader code but set in HalCoGen code

6.3 systemREG2->VCLKACON1 set differently. in bootloader version = (1U << 24) | 1 << 20U | (SYS_VCLK << 16) | (1U << 8) | 1 << 4U

in HalCoGen version = (uint32)((uint32)(1U - 1U) << 24U) | (uint32)((uint32)0U << 20U) | (uint32)((uint32)SYS_VCLK << 16U) | (uint32)((uint32)(4U - 1U) << 8U) | (uint32)((uint32)0U << 4U) | (uint32)((uint32)SYS_PLL2 << 0U);

7. In bootloader version F021 API libs are different version (2.1.00, Cortex R4BE and LE libs) then HalCoGen integrated version (only Cortex R4 LE V3D16)

Can we safely change the bootloader code to make it the same as HalCoGen generated code? For the errata code we do not have, where can we get the the libs? Can we safely replace the F021 lib from the HalCoGen version to the bootloader version? Thank You Again.