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.
Part Number: AM3358
I am working on a project where we are using the PRU-ICSS to bitbang data from an external device and save it to ddr. The code running on the PRU is written in assembly. Storing the data from the PRU into the ddr is done using the SBCO opcode. This works quite well but the constants table seems to be limited to using the first 16 MB of ddr memory. Since the linux kernel we are using also resides in this part of the memory we would like to use a different region of the ddr. If I interpreted the documentation correctly this should be possible using the SBBO opcode. However I can't seem to get this to work.
So this gives me two questions:
Attached is a small test comparing the SBCO and SBBO opcodes. Expected behaviour would be that it prints the same for both opcodes. However when running the SBBO code the ddr memory is not being written.
Hope you can give me some pointers on what I'm doing wrong.
Hello Simon, Questions for you: Are you using the PRU Software Support Package? If so, what version of the PRU Software Support Package are you using and what version of Linux? 1. Constants table entry 31 is partially programmable, so you can set the base address from 0x80000000 to 0x80FFFF00 (EDIT 9/5/2018). Using SBCO, you can write to addresses with an offset of 0x0 from the programmed base address up to an offset of 0xFFFF (this is determined by len of the DDR entry in the AM335x_PRU.cmd linker command file used in the PRU Software Support Package. Depending on the version of the PRU Software Support Package, you may need to increase it to len = 0x00010000). Also note that usage of "near" vs "far" matter when defining the constants table entries in the PRU Software Support Package. 2. The SBBO opcode should be able to write to DDR. Here's example code I wrote to use LBBO to load the value at a DDR address, SBBO should be similar: C code: #define DDR_8000_0000 (*((volatile unsigned int *)0x80000000)) uint32_t DDR0 = DDR_8000_0000; Assembler output: LDI R15.w2, 32768 LDI R15.w0, 0 LBBO &R0.b0, R15, 0, 4 Check that you are giving the PRU OCP master port access so it can read the DDR: C code: CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; // (PRU_ICSS_CFG register SYSCFG bit STANDBY_INIT) Regards, Nick
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Nick Saulnier:
Thanks for the update. After changing the address for the SBBO opcode it does indeed write to memory as expected. Upon deeper inspection it turned out that I was making an error in calculating which memory address to write to in our codebase leading to incorrect behavior. After fixing this we can address all available memory from the pru.
While looking into this issue I found this document in which the PRU used to write data into a ping/pong buffer. In the code accompanying this document a reserved-memory block is added to device tree. I've added a similar block to our device tree to reserve memory for the PRU to write to. After this everything works as expected
Thanks for the help.
In reply to Simon Wamelink:
Glad everything is working as expected! For future readers, the code Simon referenced associated with TIDA-01555 can be found here.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.