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.

AM5728: IPU Parallel Write Issues

Part Number: AM5728

I am working with a AM5728 SOM which is connected to a baseboard with two LED's attached to GPIO1_28 and GPIO1_29. My end solution will require parallel reads and writes, in a clock constrained environment, so being able to write to two GPIO's in a single clock cycle is necessary. I am attempting to solve this via using direct memory access on the IPU, such as writing data directly to the physical address. So far, I have been unsuccessful in being able to get either of the LED's to toggle (regardless of polarity of the set command).  Right now, the writes are two sequential operations, eventually it will be translated into one mask so it can be executed in one cycle.

Below is a generalized setup, on how I am attempting to write to the LEDs:

Setup:

#define LED1OutConfigRegister 0x4AE10000 + 0x00000134
#define LED2OutConfigRegister 0x4AE10000 + 0x00000134
#define LED1_RegisterShift 29
#define LED2_RegisterShift 28
#define GPIO1_Clock_Base_address 0x4AE07838
#define CTRL_CORE_PAD_GPMC_A6       0x4A003458
#define CTRL_CORE_PAD_GPMC_A7      0x4A00345C

#define LED1SetRegister 0x4AE10000 + 0x00000194
#define LED2SetRegister 0x4AE10000 + 0x00000194


*(uint32_t*)LED1OutConfigRegister &= ~(1 << LED1_RegisterShift);
*(uint32_t*)LED2OutConfigRegister &= ~(1 << LED2_RegisterShift);
*(unsigned int*)GPIO1_Clock_Base_address = (unsigned int)(0x00000101);
*(uint32_t*)CTRL_CORE_PAD_GPMC_A6     = 0x0000000E;
*(uint32_t*)CTRL_CORE_PAD_GPMC_A7     = 0x0000000E;

Writing the LED's:

*(uint32_t*)LED1SetRegister |= 1 << LED1_RegisterShift;
*(uint32_t*)LED2SetRegister |= 1 << LED2_RegisterShift;

I can't think of anything I can miss of the top of my head, are there any suggestions for driving these LED's, especially in a parallel manner?

Also, is there a means of getting the M4 to write to STDOUT on the Linux OS?

  • Lucas,

    Did you try to check the control module registers (0x4A003458, 0x4A00345c) to see if it's overwritten?
    Also, does it work with the GPIO driver from software-dl.ti.com/.../Device_Drivers.html ?

    The wiki processors.wiki.ti.com/.../Linux_IPC_on_AM57xx may help you get the M4 to write to STDOUT on the Linux OS.

    Regards,
    Garrett
  • Hi Garrett,

    After loading up the new firmware into dra7-ipu1, I performed devmem2 on 0x4A003458, and they are reading 0x0004000F, meaning the LED's are not configured to be driven. However, I am writing to that address within the M4 code, and it appears as though the values are not committing to the addresses. When I perform the same writes via devmem2 (detailed below), everything appears to work without issue (e.g. the LED turned on). Is there some configuration that needs to be changed in order for the M4 to gain access to write directly to physical memory?

    ###Set the output to operate

    devmem2 0x4A003458 w 0x0000000E
    /dev/mem opened.
    Memory mapped at address 0xb6fca000.
    Read at address  0x4A003458 (0xb6fca458): 0x0004000F
    Write at address 0x4A003458 (0xb6fca458): 0x0000000E, readback 0x0000000E

    ###Configure the Output Enable

    devmem2 0x4AE10134 w 0xEEFFFFFF
    /dev/mem opened.
    Memory mapped at address 0xb6f19000.
    Read at address  0x4AE10134 (0xb6f19134): 0xFEFFFFFF
    Write at address 0x4AE10134 (0xb6f19134): 0xEEFFFFFF, readback 0xEEFFFFFF

    ###Write to the OutputSet register

    devmem2 0x4AE10194 w 0x10000000
    /dev/mem opened.
    Memory mapped at address 0xb6f52000.
    Read at address  0x4AE10194 (0xb6f52194): 0x00000000
    Write at address 0x4AE10194 (0xb6f52194): 0x10000000, readback 0x10000000

  • Hi Garrett,

    I learned what the issue was with how I was writing to the physical memory. For IPU's, the physical memory exists at a different location than what the datasheet for the AM5728 proposes. I found the answer here:
    processors.wiki.ti.com/.../DRA7xx_GLSDK_Software_Developers_Guide

    IPU's physical space is 0x6XXX_XXXX, not 0x4XXX_XXXX.

    Lucas