• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 3487 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.

AM57x RTOS GPIO driver for M4

Chris Pendleton
Intellectual 410 points
Other Parts Discussed in Thread: TMDSEVM572X, AM5728

Hello. I am trying to get the Processor SDK RTOS v3.00.00 GPIO drivers working on the M4 cores of the AM5728. I am using the TMDSEVM572X module.

I created the test projects in the pdk folder using the "./pdkProjectCreate.sh AM572x evmAM572x little gpio m4" command. This allowed me to import the "GPIO_LedBlink_evmAM572x_m4ExampleProject" and "GPIO_LedBlink_evmAM572x_m4TestProject" projects into CCS 6.1.3.00034. These projects do not successfully build. I get errors:

gmake: *** [configPkg/linker.cmd] Error 1 GPIO_LedBlink_evmAM572x_m4ExampleProject C/C++ Problem

gmake: Target 'all' not remade because of errors. GPIO_LedBlink_evmAM572x_m4ExampleProject C/C++ Problem
Unsupported device! .xdchelp /GPIO_LedBlink_evmAM572x_m4ExampleProject line 589 C/C++ Problem

More data points: I was able to create and build the DSP equivalent driver example "GPIO_LedBlink_evmAM572x_c66xExampleProject" without any problems. I also managed to build the GPIO driver into an M4 binary to be loaded by Linux remoteproc. This crashed the processor continually. If I removed the one call to the GPIO driver then it was successfully loaded by remoteproc. The equivalent DSP remoteproc-loaded firmware with GPIO worked as expected. I suspect these issues are related.

Thank you for your assistance.

-Chris

  • 0
    TI__Guru**** 393215 points
    I have notified the RTOS team. They will respond here.
  • 0
    TI__Guru** 114410 points

    Chris,

    I am not seeing the issue that you are reporting with my setup. I am able create the project, build it and then run it on the EVM.

    From the data points that you have provided, I suspect that there might be a setup issue that is causing this problem. Can you right click on the Project and do a clean project. Also go to build properties and ensure that your RTSC settings is as shown below:

    also, go to CCS General ->Main settings and check to make sure no linker command file is used in the field "Linker Command File:" under Advanced settings.

    Now rebuild the project and let us know if the issue persists.

    In terms of the Linux setup, I think you need to remove the GPIO from your dtb file if you want one of the slave cores to control the GPIO but I will let an Linux expert confirm this change.

    Regards,

    Rahul

  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 43296 points
    Hi Chris,

    I just build the GPIO_LedBlink_evmAM572x_m4ExampleProject but don't see any issue, can you attach your complete build log here so I may be able to find the difference?

    Regards,
    Garrett
  • 0 in reply to Rahul Prabhu
    Intellectual 410 points

    Hi Rahul. Thanks for the quick response.

    I located the build error. The ti.platforms.evmAM572X files were corrupted. The clue was in the console "The DRA7XX device is not currently supported". I restored the bios_6_45_01_29 folder containing these files and the project now builds.

    Regarding your Linux comment, I was able to toggle the USR LED GPIOs with the DSP application without modifying the dtb file. This makes sense to me because Linux is configuring the USR LED pinmuxes to be output GPIOs. I did need to remove all initialization code in the example for this to work. The same M4 code crashes the processor, however:

    [   10.562228]  remoteproc0: remote processor 58820000.ipu is now up

    [   10.994634]  remoteproc0: crash detected in 58820000.ipu: type device exception

    [   11.002021]  remoteproc0: handling crash #5 in 58820000.ipu

    [   11.009038]  remoteproc0: recovering 58820000.ipu

     

  • 0 in reply to Chris Pendleton
    Intellectual 410 points

    I would like to investigate why this crash is happening. I am pretty sure that that I am running the same code on the DSP, where it blinks the USR0 LED and works as expected. My project is located here, and should import into CCS:

    http://ptcusa.com:90/misc/x15_ipu1.zip

    This is a modified project with code from the IPC linux elf ex02_messageq example and GPIO example. It should be loaded my remoteproc0, start up a task, and blink the USR0 LED forever.

    See line 126 in MainIpu1.c:

    while(1)
    {
    AppDelay(0x6FFFFFU);
    high();
    AppDelay(0x6FFFFFU);
    low();
    }

    where high() and low() map to GPIOPinWrite(GPIO_BASE_ADDR,14,GPIO_PIN_VAL_HIGH); and GPIOPinWrite(GPIO_BASE_ADDR,14,GPIO_PIN_VAL_LOW); in gpio_ptc.c line 195.

    If I remove the while(1) loop, the program works as expected. There is no crash and I see the log messages in the remoteproc0 trace0 log. As soon as I add a call to GPIOPinWrite(), the processor crashes as shown in the above post. A single call without the while(1) loop is all it takes to crash.

    Again, this same code works on the DSP so I am surprised that it doesn't work on the M4. I certainly don't expect it to crash the processor.

    Any ideas?

    Thanks,
    Chris

  • 0 in reply to Chris Pendleton
    TI__Mastermind 43296 points

    Hi Chris,

    Due to the bit-banding feature in IPU(M4), the MMU configuration for physical/virtual address translation are different between DSP and M4, see the IPC resource table for the MMU config in DSP and M4 MMU:

    ./packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h

    #define L4_DRA7XX_BASE          0x4A000000

    #define L4_PERIPHERAL_L4CFG     (L4_DRA7XX_BASE)

    #define DSP_PERIPHERAL_L4CFG    0x4A000000

    ./packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h

    #define L4_DRA7XX_BASE          0x4A000000

    #define L4_PERIPHERAL_L4CFG     (L4_DRA7XX_BASE)

    #define IPU_PERIPHERAL_L4CFG    0x6A000000

    You can find the definitions of these macro here:

    hence, typically you need to add 0x2000_0000 in M4 for the address access in the region 0x4A000000 which includes the GPIO registers. Linux RemoteProc will report the M4 core crash when there is any illegal memory access, in this case, for example:

    *(unsigned int*)0x4A009770 = (unsigned int)(0x00000102);

    in gpio_ptc.c.

    For bit-banding feature and IPC specifics, you can refer to

    Regards,

    Garrett

  • 0 in reply to Garrett Ding
    Intellectual 410 points

    Thanks very much Garrett. That was very helpful. I was only peripherally (haha) aware of the bit-banding feature in the M4. I added 0x2000_0000  to the addresses and things work as expected. 

    Regards,

    Chris