• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 605 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.

MCU-PLUS-SDK-AM263X: Spinlock examples not working?

Barna Csenteri
Expert 1890 points

Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: AM2634

Tool/software:

Hi

Trying to run the spinlock example from project wizard (sdk is MCU+ SDK for AM263x 9.2.0.56)

1. I can get to this point with 4 cores only after a full reset of the devboard (on stopping and restarting debug I can't, only core1 has the breakpoint in main, the other 3 are running by default - probably core 1,2,3 hangs from previous run).
I have seen this thread which suggests a reset - I would like to know if this is the final solution to fix this issue?

2. I can't manage to get over the IpcNotify_syncAll(SystemP_WAIT_FOREVER); line.
All I get in the console is: 
[IPC Spinlock Sharedmem] Example started ...
Waiting for all cores to start ...

This project in theory is loaded into all cores and the first two has the spinlock defined.
If debug is started on all cores (prev screenshot) this IpcNofity_syncAll should not be passed?

What do I miss? 

The IPC setting was not changed and looks like this:

What I am not sure about are the gel files - by default only core0 has it set, it is empty for the rest.


Should this be set for all of them? Tried just in case, no change :)

I have seen suggestions on other threads to remake project from scratch to make it work but I did not succeed. 

Just for the sake of testing I tried two more projects:

- ipc_notify_echo_am263x-cc_r5fss0-0_freertos_ti-arm-clang: locks into ipc_notify_echo_main_core_start/IpcNotify_syncAll(SystemP_WAIT_FOREVER); 
Did restarted the devboard on all occasionsto reset all cores.

- ipc_safeipc_echo_am263x-lp_r5fss0-0_freertos_ti-arm-clang but that one has some errors:

Best regards

  • 0
    Expert 1890 points

    The point 2 was my mistake - imported the wrong project, the system one has to be loaded which loads the two other ones.

    Runs well, the only thing remained is point 1 which forces me to reset everything on every debug session.

    Tried method with restart but it does not works (project does not boots up correctly)

    What worked for me is the reset pin on the devboard or a complete POR. 

    I would definitely need a clean shutdown and restart from software with clean CPU's without hanging so I would need a solution for this

  • 0 in reply to Barna Csenteri
    TI__Mastermind 25283 points

    Hello Csenteri,

    Can you confirm that both clusters of the device are operating in Dual-core Mode during the execution? 

    The GEL files loaded to R5FSS0-0 take care of configuration and release of all 4 cores of the device.

    One idea I would suggest is to "Group" your cores together in the debug session as described here: https://software-dl.ti.com/ccs/esd/documents/ccs_multi-core-debug.html#fixed-group

    With the cores grouped together, when you apply a GEL reset function, it will be applied to all 4 cores and not just R5FSS0-0.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Expert 1890 points

    Hi Zackary

    Fleenor said:
    Can you confirm that both clusters of the device are operating in Dual-core Mode during the execution? 

    I am still learning the multicore part and this is a setting what I did not found yet. Can you point me in the right direction?
    Tried to search after it in the SDK docs but did not found too much except some lines in the release notes :) 

    If You mean lockstep vs individual cores they should be individual cores running two different firmwares since the project itself is the unmodified SDK one thus all settings are from those and the spinlock works ok running on the first two cores:

    Fleenor said:
    One idea I would suggest is to "Group" your cores together in the debug session

    This is good one, might help a bit in debugging.

    For me not really the debug is the most important (reset button on the devboard helps) but a gracious shutdown of a firmware. Our case because of requirements will have two set of firmwares - one is the service one, another is the application. They need to be separate firmwares and we need to be able to switch between them (special security) without having issues with crash or hanging on some of the CPU's like this example does. Basically we need to do a clean reboot. I hope this will be possible without a POR. Our case will be even more complicated than the examples (we will have the AM2634 having two pair of cores in lockstep).

    Best regards,

    Barna

  • +1 in reply to Barna Csenteri
    TI__Mastermind 25283 points

    Hello Barna,

    It's important to recognize that the device is designed as 2 clusters of 2 cores each. Each cluster (R5FSS0 and R5FSS1) can be configured to operate in either Dual-core mode or Lock-step mode by utilization of the GEL file functions (Configure_Dual_Core_mode and Configure_Lockstep_mode) or (R5F_SSx_Reset_Dualcore, R5F_SSx_Reset_Lockstep, and Dual_core_switch). Screenshots below show these options available from the R5FSS0-0 debug context.

    I believe the SoC_Warm_Reset function may be of use here based on your description of the reset requirements. This will perform a clean reboot of both clusters without the need for using the PORz hardware button.

    There are also SDK API's available for the same function via the SoC_RCM module.

    SOC_rcmR5SSxPowerOnReset() (POR Reset) and SOC_rcmR5SS1TriggerReset() (Warm Reset)

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/09_02_00_56/exports/docs/api_guide_am263x/group__DRV__SOC__RCM__MODULE.html#ga6bd7b4f07c83955654edfc3c5bc859d8

    Please experiment with these and let me know if this helps you move forward in you development. 

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Expert 1890 points

    Hi Zackary

    I think the POR will solve it for us. 

    I am also looking into the documentation of memory map when in lockstep vs when in not, OCRAM vs external RAM, what can be shared between CPU's and when etc.

    Started to look into memory requirements and the 256k for one core seems to not be enough for what our client want implemented so I want to be sure I understand this modes specially because the doc says QSPI boot is not XIP, thus everything is loaded into the RAM.

    Is there a good starting point document for this? I did found  this one and also digging through the tech ref manual but if there is any application note or SDK reference I did not found yet which is about this please let me know ...

    TY for the help, it is really appreciated.

  • 0 in reply to Barna Csenteri
    TI__Mastermind 25283 points

    Hey Barna,

    Glad to hear that solution will work.

    I would suggest looking into the AM263Px device which supports OSPI/QSPI XIP and Optiflash technologies as well as larger TCM (256 KB per Cluster).

    We should have an app note available for optimal utilization of AM263Px OSPI/XIP/Optiflash soon. I will also check with the team internally if anything similar may already be available.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Expert 1890 points

    Hi

    The APP note would be nice, I am specially interested in the performance hit when running XIP and any timeline on this version:

    • AM263P Flash-in-Package (ZCZ_F) variant includes 8MB OSPI Flash

    I could not see any ZCZ_F on the currently sold 3 versions. 

    Best regards,

    Barna

  • 0 in reply to Barna Csenteri
    TI__Mastermind 25283 points

    Hey Barna,

    Requesting that you create unique E2E threads regarding these queries so we can get the right folks involved.

    Best Regards,

    Zackary Fleenor