• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 4416 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.

F28069 FLASH API: Flash_Erase never returns

David R.
Expert 1295 points
Other Parts Discussed in Thread: TMS320F28069

I'm working with the Boot ROM-resident FLASH API on a TMS320F28069. I verified that Flash_CPUScaleFactor and other defines are set correctly using Flash2806x_ToggleTest(), whose output frequency was right on at 10KHz. The FLASH API functions are linked directly into the BOOT ROM address space; the map file indicates:

003ffebb _Flash2806x_Program
003ffebd _Flash2806x_Erase
003ffef3 _Flash2806x_APIVersionHex

Speaking of APIVersionHex: it comes back with 0x0100, so the fundamental linker configuration appears to be OK. I am linking in the "2806x_BootROM_API_TABLE_Symbols_fpu32.lib" version of the library, and the compiler is configured with "--float_support=fpu32".

After performing the same initialization, I call Flash2806x_Erase(SECTORH, &EraseStatus); (with EraseStatus declared as FLASH_ST type) but the function doesn't return within several minutes of waiting. After pausing, the debugger reports that the CPU is stuck in an infinite loop at 0x3FF788, which the disassembler shows as "SB 0, UNC" and which appears to be part of the Bootloader Functions segment of BOOT ROM.

Interestingly, once the debugger is paused, the Memory Browser shows the entire contents of the FLASH memory (including the CSM locations!) as 0x0000. Neither the WDFLAG or MCLKSTS bits are set. After a reset and restart (without reloading) the previous contents of FLASH are again shown correctly in the Memory Browser.

Can someone point me at what I'm doing wrong here?

Thanks,
Dave 

  • 0
    Expert 1295 points

    Bumping this thread... I've made some improvements and discovered some new issues, but still have not found a resolution...

    I'm able to successfully run the Example_Flash2806x_API project, so I started to look for differences between this and mine. The largest difference is that my project is a DSP/BIOS project.

    Looking deeper into what happens after I make the call to Flash2806x_Erase(), I started checking for stack overflow. Since DSP/BIOS sets up the stack beginning at 0x0000 with 0x0600 length, I set a hardware watchpoint for writes at 0x0600. After calling Flash2806x_Erase(), the watchpoint triggers: the PC is at 0x348A0B, an invalid address that the memory map shows as "Reserved". Assembly stepping from here shows the stack steadily growing until it reaches the PIE vectors at 0x0D00. Shortly thereafter, the processor vectors into the bootloader and runs to the trap loop at 0x3FF788.

    Clearly, we're in the weeds here and something in the BIOS configuration is butting heads with the FLASH API. Can anyone get me pointed in the right direction to figure out what?

    Thanks,
    Dave 

  • 0 in reply to David R.
    Expert 1295 points

    Can any TI folks or CCS experts shed any light on how to determine where the failure is actually occurring in this code? Since the FLASH API runs from BOOT ROM, I don't know how to figure out just where the processor is ending up in the weeds.

    I've used assembly stepping to confirm that the function call to Flash2806x_Erase() successfully vectors to the BOOT ROM API table. From there, it successfully branches into the FLASH API segment of the BOOT ROM. I didn't want to continue single stepping from here however, since the FLASH API documentation indicates that precise timing is necessary within the Flash2806x_Erase() routine.

    After allowing the processor to free-run once I've confirmed it's inside Flash2806x_Erase(), it hits my 0x0600 watchpoint almost immediately, indicating a blown stack and a PC attempting to fetch instructions from non-existent memory...

    Thanks,
    Dave

  • 0 in reply to David R.
    Expert 1295 points

    After linking rts2800_fpu32.lib into the project, I now hit ILLEGAL_ISR any time I try to call Flash2806x_Erase() or Flash2806x_Program() API functions. After hitting the ILLEGAL_ISR, I decided to take a look at the stack; the SP is up at 0x0616, indicating that the stack has overflowed.

    The stack contains a repeating pattern up through 0x800, shown here with the red lettering indicating words that have changed since I called the Flash2806x_Erase() function:

    The 0xBEEF (unchanged) locations are preset by the DSP/BIOS application entry function (i.e. before the call, this entire block of memory reads 0xBEEF). The 0x3DC5C4 address, seen in multiple spots in the repeating overflow pattern, is closest to 0x3DC5C3, the location of the _ILLEGAL_ISR symbol in FLASH. 

    Interestingly, attempting to step into the ILLEGAL_ISR body fails; the PC is stuck at 0x3DC5C3, and the stack continues to grow with each "step-into" operation.

    Dave

  • 0 in reply to David R.
    Expert 1295 points

    Alright, figured it out. Posting the solution here for posterity, in case any other unfortunate souls Google their way here after meeting the same fate:

    The example declares 2 dummy variables that slide the Flash_CPUScaleFactor and Flash_CallbackPtr into the correct locations in memory, which I missed and did not include in my project. It would be more robust to do this explicitly with separate linker sections, but TI's approach gets the job done:

    // Dummy variables for header file structure.
    // Without these declarations Flash_CPUScaleFactor and
    // Flash_CallbackPtr will not end up in the correct place.
    #pragma DATA_SECTION(EmuKey,"EmuKeyVar");
    #pragma DATA_SECTION(EmuBMode,"EmuBModeVar");
    Uint16 EmuKey;
    Uint16 EmuBMode;

    Doing this much resolves the crash issue. But for those using the PIE, it leaves a glaring bug: setting Flash_CPUScaleFactor and Flash_CallbackPtr overwrites entries in the PIE vector table.

    If using the PIE, it's probably advisable to disable it before calling into the FLASH API, which will remap vector fetches to the BOOT ROM's vector table. Before initializing them, cache the existing values for Flash_CPUScaleFactor and Flash_CallbackPtr, and restore them after finishing with the FLASH API, but before re-enabling the PIE.

    *facepalm* :)

    Hope this helps,
    Dave 

  • 0 in reply to David R.
    Intellectual 285 points

    Thanks Dave...

    you helped this soul :).

    Cheers,

    -Varun

  • 0 in reply to David R.
    Expert 1585 points
    You helped this soul too. =)

    Thank you!