• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 664 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: Dual core booting from flash - CPU2 will not EALLOW

Dave Winterborne
Prodigy 200 points
Part Number: TMS320F28379D


I have developed a dual core (+CLA1) project and want to migrate it to run from the on-chip flash for standalone operation.

When running from RAM, everything works as it should, and I can monitor operation via the debugger.

I believe I've taken all the necessary steps to boot and run from flash:

  • All initialised code is linked to flash in both CPUs, as confirmed in Memory Allocation, including BEGIN
  • The function for setting up the flash control registers (InitFlash) is stored in the .TI.ramfunc section, which is loaded to flash but run from RAM. It is copied from flash to RAM in InitSysCtrl(), and I can see from the Memory Browser that the code is copied over.
  • The code to initialise the PIE vector table is there, but is not yet being reached.

When I run the application (Build code for both CPUs with the correct linker command file, connect the debugger and load to both CPUs with auto run disabled, and run CPU1, then CPU2), CPU1 copies Ramfuncs to RAM, initialises the flash control registers, tries to boot CPU2 via the IPC (IPCBootCPU2), and waits for the successful boot flag from CPU2.

CPU2 also copies Ramfuncs to RAM, but when the EALLOW command in InitFlash() is reached, it steps to 0x3FE00A and the debugger indicates "no symbols are defined".

I suspect some sort of security protection is involved. The CPUWRITE and CPUFETCH bits of the Access Protection NMAVFLG register in CPU2 are set. In CPU1, the CPUWRITE bit of the MAVFLG register is set. 

All the fields (except the reserved ones) of the Dual Code Security Module RAMSTAT and SECTSTAT registers, in both CPUs, are set to 3, indicating they are unsecured, so I assume this isn't a DCSM issue?

Any assistance with this would be appreciated. Thanks.

  • 0
    TI__Expert 4195 points

    Hi Dave,

    I think CPU2 is in the ITRAP ISR (0x3FE00A). You can confirm this by loading the symbols and pointing to the source file. The symbols and source files are available in below location.

    C2KwareInstallationPath\libraries\boot_rom\f2837xd\revB\rom_sources\ccs_files\cpu02\Release

    C2KwareInstallationPath\libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu02-bootROM\source

    From your description it looks like cpu2 is accessing RAM which is not allowed access from it. Can you confirm the settings in the FETCHPROTx and CPUWRPROTx bit fields.

    Regards, Pawan

  • 0 in reply to Pawan Nayak
    Prodigy 200 points

    Hi Pawan,

    Thanks for your reply.

    CPU2 was indeed in the ITRAP ISR, as confirmed by loading the symbols and pointing at the source as you described.

    By comparing the current linker command file with the original TI supplied version, I was able to isolate the cause of the problem: the .TI.ramfunc section was being linked to run from GS RAM locations that CPU2 is not configured as master for in the Memory Configuration Register GSxMSEL. This section had been changed to run from GS RAM rather than LS RAM by a former colleague, possibly because the same reallocation has been done in CPU1 to allow LS0-3 to be used for the CLA program/data.

    I have some further issues with booting and running my application from Flash, but they are different, so I'll mark this as resolved and start a new thread for those if necessary. Thanks.