• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 187 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C123AH6PM: Flashing NVM

Carter Myers
Prodigy 80 points
Part Number: TM4C123AH6PM

We have developed an internal boot loader that runs out of protected flash memory which flashes NVM program space.

Recently we have run into devices failing to flash NVM using this bootloader routine.

 

The only potential corrective action we have identified is lowering the system clock from 80mhz to 10Mhz before erasing flash NVM and then programming flash NVM.

 

Please confirm a clock  frequency change from 80Mhz to 10 Mhz will ensure successful flashing of NVM on the TM4C123AH6PMI7 processor.

  • 0
    TI__Guru**** 159225 points

    Hi,

      Any reason why the TivaWare bootloader is not used? The TivaWare bootloader does not run at 80Mhz but rather the default PIOSC (16Mhz) after reset. All the timings for programs and erases will be based on the 16Mhz. I think this may explain why on your custom bootloader the10Mhz works rather than 80Mhz as 80MHz will have reduced the program and erase pulse widths. 

  • 0 in reply to Charles Tsai
    TI__Prodigy 80 points

    Just to ensure I understand clearly, the processor clock must be set to 16 Mhz any time a flash block erase command or write command to flash memory occurs?

    We are currently using the following Tivaware functions in ROM to execute these tasks:

    ROM_FlashErase()

    ROM_FlashProgram()

  • 0 in reply to Carter Myers
    TI__Guru**** 159225 points

    Hi Carter,

      By default after reset the processor is running at 16Mhz from the PIOSC. You don't really need to set it. 

  • 0 in reply to Charles Tsai
    TI__Prodigy 80 points

    We configure the clock after reset to run at 80Mhz for normal code execution.

    Can the following TIVAWare ROM commands be used reliably when running @ 80Mhz?

    ROM_FlashErase()

    ROM_FlashProgram()

  • 0 in reply to Carter Myers
    TI__Guru**** 159225 points

    Hi,

      There is no issue to run these two APIs at 80Mhz. Can you check the returned value after you call them? Are they returning errors or not?

  • 0
    Prodigy 40 points

    I am unclear why we must set the clock at 16Mhz when referencing ROM_FlashErase() and ROM_FlashProgram() when executing the  boot loading routine in protected flash memory space ,  but it is ok to perform these operations at other times using the 80Mhz clock. Only ROM_ function calls are executed out of protected flash memory space within the boot loading routine. Bootloading routine fails at ROM_FlashErase() function call unless clock is significantly lowered >16Mhz.We are disabling all interrupts and watchdog timer prior to calling the boot loading routine. Another post 

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/367605/possible-tm4c123-hardware-bug 

    suggests this may be related to an instruction fetch / pipeline issue. Just seeking a solid answer why this is occuring to ensure lowering processor  clock rate is a valid corrective action.

  • 0 in reply to Mike Tetmeyer
    TI__Guru**** 159225 points

    Hi Mike,

      Thank you for digging the relevant post out. Honestly, I have not come across this issue after I come on board supporting this product the last few years. It was my mistake to say that FlashErase and FlashProgram should work at 80Mhz with code running out of flash without realizing that a similar problem has been reported in the past. The reason I thought 16Mhz would work is because the TivaWare bootloader runs at 16Mhz using PIOSC.  I have not seen any reporting of it not working. Looks like there are several factors that the TivaWare bootloader does not run into the issue as reported. They are 1) the code runs at 16Mhz which is less than 40Mhz and 2) at such frequency (16Mhz) the prefetch buffer is not enabled and 3) the program and erase code is run out of SRAM and 4) no interrupts are enabled during bootloading. The bootloader design just happened to avoid the issue not by intention but rather the architecture of it does not require it to run at full SYSCLK. Per suggestion by Amit in the post your refer, it will be best to run the code out of SRAM when you program and erase the flash. Please refer to the bl_startup_ccs.s file for the bootloader code that first copies the bootloader from flash to SRAM.