• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1254 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.

CCS/AM4379: Access same memory addresses on ICSS0 and ICSS1

Simon Friedrich
Prodigy 40 points
Part Number: AM4379

Tool/software: Code Composer Studio

Hello,

I want to access the same memory adresses using ICSS0 and ICSS1. One should use address 0x0004_0000 in order to read/write memory adress 0x0000_0000 as it is said in chapter 30.3.1.2 in TRM. So I tried to work with this offset, but I got a strange result:

As you can see in the picture, the system seems to override the lower bytes if you want to save more than 4 bytes.

Best regards

Simon

  • 0
    TI__Guru**** 161600 points
    I've notified the sw team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Genius 10440 points
    Simon,

    I've replicated this issue on my setup. It appears like the SBBO instruction is the one that stores the 6 bytes in a single memory location with the wrap around. What I'm seeing through, is that this only occurs when writing to the other PRUSS DRAM while using the 0x40000 offset method. If I use the full 32 bit global address for the same memory (0x54400000) then all 6 bytes are written into different memory locations (correctly). Also, if I write to the local DRAM memory (instead of the other PRUSS's memory) then the bytes are stored correctly as well.

    This seems like a silicon bug while performing the address translation (from 0x40000 to 0x00000 in the other PRUSS). I've notified the silicon designers to see if they were aware of this issue and I will let you know if there is a workaround.

    For now, you can either use 1 SBB0 instruction per 4 bytes of data (while using the 0x40000 offset to put the data into the OTHER PRUSS), or use the global address of the memory you are writing to (0x54400000 in this case).

    Jason Reeder

    P.S. When I go into the DATA RAM memory and poke in the correct values (for all 6 bytes) I can see the LBCO instruction pull in 6 bytes into R4 and R5. So, the LBCO instruction works as expected in this case.
  • 0 in reply to Jason Reeder
    TI__Genius 10440 points

    Simon,

    After a bit more testing and some back and forth with the IP designers. This still looks like a silicon bug with the byte burst operations while using the local bridge between PRU Subsystems. I confirmed that if you attempt a byte burst read operation (LBBO or LBCO in your case) from the address 0x00040000 then you will read from the same address twice (the same way that the SBBO stored to the same address twice while using address 0x00040000).

    Knowing this the workarounds remain the same as what I posted above, either use the local bridge (0x00040000) and write/read 4 bytes with each instruction (~7 PRU cycles per 4 byte read) or you can use the 32 bit global address for the memory location (0x54400000) and read/write multiple bytes with each instruction (~33 PRU cycles for a 4 byte read with larger bursts bringing the average cycle time down).

    So, if your burst read size is less than 16 bytes, it will always make more sense to use the local bridge and 4 LBBO operations. However, at some point beyond 16 byte burst sizes it will make sense to switch to a single LBBO operation using the global 32 bit address.

    Jason Reeder

  • 0 in reply to Jason Reeder
    TI__Genius 10440 points
    I should clarify that byte burst operations that stay within one PRUSS do not have any issues. So in your case, your PRU that does the read (LBCO) is reading its local DRAM so it does not have any issues.

    The issue only arises when one PRU accesses the DRAM of the OTHER PRUSS using the 0x00040000 address offset.

    So the cycle count tradeoffs for the read times are only applicable if you need to read from the OTHER PRUSS DRAM.

    Jason Reeder
  • 0 in reply to Jason Reeder
    Prodigy 40 points
    Thank you for helping me. So I have to concentrate on working with 4 bytes till the bug is fixed.

    Best regards
    Simon