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.

F28M35 FlashInit / FlashGainPump problem after Bootloader

Other Parts Discussed in Thread: TMDSDOCKH52C1, UNIFLASH, CONTROLSUITE

Dear Support,

we use a F28M35H52C1 at the TMDSDOCKH52C1 Kit. At the moment we are developing a bootloader for our main application. For the M3 CPU we are a the point that we can programm our main application via the bootloader and jump to the main application. (The C28 CPU is ignored at the moment)

In the main application we get a FaultISR directly after FlashInit or in FlashGainPump function. Leave this part out via the debugger the rest of the application seems to work. (testet communication via Uart). Before leaving the bootloader we disabled the interrupts and called FlashLeavePump().

Programming the main appilcation via CCS (6.0.1.00040) everything runs fine as it should.

Info about Jump to the main application:

Setting the _c_int00 address:

		boot: load = 0x21a694
		{
			-l rtsv7M3_T_le_eabi.lib<boot.obj>(.text)
		}


Jump from the bootloader:

int main(void) {

...

  Main_SpringeZuHauptprogramm(0x21a694 + 1);
  return 0;
}


static void Main_SpringeZuHauptprogramm(unsigned long address) {
 __asm(" mov sp, r0\n"   // sp is now *address
   " bx r0\n" );     // jump to *address
}

Flashinit routine:
void FlashUserInit() {

  Fapi_StatusType oReturnCheck;

  DCSMUnlockZone1CSM (&Zone1KEY);
  DCSMUnlockZone2CSM (&Zone2KEY);
 
  memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

  FlashInit();

  FlashGainPump();

  oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 100);
  if(oReturnCheck != Fapi_Status_Success) return; // TODO Fehlermeldung
  oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
  if(oReturnCheck != Fapi_Status_Success) return; // TODO Fehlermeldung

}

    HWREG(SYSCTL_MWRALLOW) = 0xA5A5A5A5; SysCtlClockConfigSet(SYSCTL_USE_PLL | (SYSCTL_SPLLIMULT_M & 0xA) | SYSCTL_SYSDIV_1 | SYSCTL_M3SSDIV_1 | SYSCTL_XCLKDIV_4); and     SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG1);  SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG0); are called in the main init routine before FlashUserInit.

Since the the main application works without the bootoader, the malfunction must have something to with the bootloader.

Thanks for your help in advance


Mathias

  • Mathias,

    1) Make sure that FlashInit() function gets executed from RAM.

    2) From the code, looks like you are executing at 100MHz.  Make sure that RWAIT is configured as 0x2 in the FlashInit() function.

    3) Make sure you program ECC for the application executing from Flash.  If ECC is not programmed, ECC errors will occur for Flash reads/execution.

    4) Make sure you did not remove the loop for 7 NOPs at the end of the FlashInit() function.

    Thanks and regards,

    Vamsi

  • Dear Vamsi,

    thank you for your hints.

    1 - That is my program doing
    2 - RWAIT is automatically set to 0x1 in FlashInit(), regardless what is set in RWAIT before, but as i read in TRM, for using this register is it automatically add 0x1 in every case. So here should be everything all right
    4 - Don't now how i could do this, but from debugging i now for sure that this lopp exists (and it is running in RAM)

    After some testing Point 3 could sovle my problem. This wasn't set in the bootloader, as i took the FlashRoutine from the main application and i used Fapi_DataOnly for storing settings bytewise
    When flashing the bootloader and the main application via Uniflash, starting the main application via the bootloader works fine.
    So Point 3 is very likly at the moment. This leads me to a question, since in Fapi_AutoEccGeneration mode only 8 or 16 byte can be programmed. As i get the data bytewise and there is no guarantee about the order in hex format, is it possible to write everytime 8 bytes, 7 of them are 0xFF and the eight would be the acutal databyte? Or would that confuse the ECC calculation? And when what Method would you suggest?

    Best regards


    Mathias

  • Mathias,

    Regarding RWAIT:  For 100MHz, RWAIT has to be 0x2.  See below is the code snippet taken from FlashInit() function located at C:\TI\controlSUITE\device_support\f28m35x\v203\MWare\driverlib\flash.c.  It clearly writes a value of 2 in RWAIT for 100MHz.

        // Set waitstates according to frequency
        //                CAUTION
        // Minimum waitstates required for the flash operating
        // at a given CPU rate must be characterized by TI.
        // Refer to the datasheet for the latest information.
        #if CPU_FRQ_125MHZ
        HWREG(FLASH_CONFIG_BASE +
              FLASHCTRL_O_FRDCNTL) = (3 << FLASHCTRL_FRDCNTL_RWAIT_S);
        #endif
    
        #if CPU_FRQ_100MHZ
        HWREG(FLASH_CONFIG_BASE +
              FLASHCTRL_O_FRDCNTL) = (2 << FLASHCTRL_FRDCNTL_RWAIT_S);
        #endif
    
        #if CPU_FRQ_75MHZ
        HWREG(FLASH_CONFIG_BASE +
              FLASHCTRL_O_FRDCNTL) = (1 << FLASHCTRL_FRDCNTL_RWAIT_S);
        #endif
    
        #if CPU_FRQ_60MHZ
        HWREG(FLASH_CONFIG_BASE +
              FLASHCTRL_O_FRDCNTL) = (1 << FLASHCTRL_FRDCNTL_RWAIT_S);
        #endif

    Regarding ECC:  When you use AutoEccGeneration, you must program 64-bits at a time.  You can not reprogram part of the 64-bit slice later since ECC is already calculated and programmed for the 64-bit slice.  If you can not program all the 64-bits at a time, you can program the data only at first and then once you have all the 64-bits available, you can reprogram the same data with AutoEccGeneration (ofcourse you have to disable ECC until you program ECC to avoid ECC errors).    

    Thanks and regards,

    Vamsi

  • Update:

    In the last weeks, i hat unfortunately less time for this project.

    3) Make sure you program ECC for the application executing from Flash.  If ECC is not programmed, ECC errors will occur for Flash reads/execution.

    Seems to solve the problem at the M3 CPU. The first tests were succsesful.

    Thank you for your help.