Hi Jeff Hope all is well good to here from you Yes saw that I think that's why someone told Walter there's no way to get code into PRU with CCS. It's obvious that the poster was using CCS fine to debug PRU code it's only the examples with RPMSg where JTAG is blocked. This to me means the ARM has a Lock on some shared resources. I've also seen comments take the Linux SD card out🤔 when using CCS JTAG. The PRU resources are so limited I'm thinking any PRU application would need to remove RPMSG after the application is working. it's really a glorified printf debugger . In the event you see PRU freezes or crashes JTAG is invaluable and you could remove the Rpmsg from the code while debugging.
Back to your DSP comments Jeff. On OMAP4 the key to debugging the DSP with CCS was a gel file that basically holds ARM off from interfering. If you look at the link I provided and re-read the user provides his gel script in theory if your PRU or DSP code needed no muxing done by the ARM you debug your DSP or PRU code with CCS and JTAG and you dummy up input Data from ARM but you hold the ARM in reset while you debug the PRU or DSP. We did that on a OMAP L 138 the DSP ran the Matlab control theory loop. DSP can access DDR and a big shared SRAM. Once our ARM DSP IPC all worked you really can't debug one side it's like halting a wifi transmission in the middle the communication will fail right. My point is you hold off the ARM with a gel script hold it in reset then load a gel script that initializes the DDR Ram and loads the code and starts the DSP. The problem these gel files are inhouse TI tribal knowledge or seem to be lost between CCS version. A good example is the Am335x SDK has those same example you were running on 57x with a PRU CCS JTAG tutorial. I went through that on a Beaglebone white and CCS 6.0 the PRU_CAPE. Gel file was flakey I had no Cape. It was good enough to re learn CCS 6 on am335x on windows 7 but I quickly punted I'm running CCS 10 on windows 10 on the Beaglebone white which has JTAG built in. But get this they abandoned Starter ware they folded it into the SDK Linux PDK the .org page says starterware is supported it's not. It also says that you can use the Linux SDK on any version of Linux so I think Cheng started installing it on the Beaglebone bone yikes. This am335x PRU is very limited. We used one PRU for a UART for DSP and the other PRU was an LCD segment controller. We also a TI 28xx quadrature encoder the DSP read over SPI. The clock on these DSP is way faster than a PRU. The DSP control loop ran ever 100 nS. This PRU at 200MHZ that's 50 instructions in assembler it couldn't work as hard as a DSP. Walter has a fairly simple loop he had working on ARM side reading ADC but he was getting unacceptable delay so he's learning PRU. I don't know my Beaglebone white really isn't supported anymore I've got a barebones ARM ADC running on it I'm unwilling to give up JTAG and CCS I do have several black's and the JTAG sockets but don't feel soldering ambitious. my Am335x SK EVM already runs SDK Linux has JTAG onboard and has more memory like the black. Looks like I was building uboot on a Linux Ubuntu laptop I definitely remember building SDK Linux kernel and running defconfig and finally learned how to add remove module's and features from the kernel that was in 2015. I guess it's better late than never my only concern is that pin muxing of that SDK kernel has to be outdated but I'll take the risk if I can build my Kernel's source's. You can't deliver a product if you can't rebuild source code right Jeff??? Still there.🤔 On barebones ARM pinmuxin depending on what peripherals you need on your project that's why starterware is no longer supported it becomes ifdef nightmare but the c code is obvious. it's the cache, MMU code that's complex then fold in open source TCP/IP wow no way you going to get a barebones ARM project going in less a year's using console uart printfs. That FTDI UART/ JTAG onboard the devboard the hardware guys were old school they definitely knew what someone doing low level development needed. That was the Beaglebone white and the $200 am335x SK The black ditched the JTAG onboard and doubled the RAM. Unfortunately everyone using anything after the bone black hasn't hair Left 🤣 because they spend their Life waiting on printf from DSP on x15 and PRU. Win 10 CCS10 Black hawk x15 your blazing Jeff unfortunately I don't see anybody beyond you in this group seeing the value of CCS. Most of these guys on this group are ARM Linux application guys they don't need CCS for that. And anybody else using the X15 DSP will probably use RPMSg. I want to stay positive but I can't make a $$$ investment in any .org board again that doesn't have a working JTAG connector on it so if I want to do DSP I gotta go backwards to my OMAP L138 board. For you I can check out all the .gel that came with CSS 10 as well as what gels come in the 57x SDK you should not have any problem loading up DSP CCS code. Pull the Linux SD card out on x15 I mean you're learning signal processing on 67x right. CCS and JTAG are the default TI DSP tools for at least 10 years Mark Sent from Yahoo Mail on Android On Tue, May 4, 2021 at 7:30 PM, Jeff Andich<[email protected]> wrote: Very informative thread guys! Interesting article in E2E on accessing shared memory and RPMsg.. This statement by Jason Reader “…Also, if you are testing an RPMsg project you will need to use the pruss_remoteproc Linux module to load the code and not CCS over JTAG. …” could be a clue as to the issue I was having attempting to load the C66 with JTAG after remoteproc initially loaded the RPMsg example project. The stock example program was referred to in a post a couple of months ago ( https://forum.beagleboard.org/t/status-running-ti-sdk-built-c66-dsp-example-exe-on-bb-x15-beagleboard-debian/27469). If I allowed remoteproc to load the C66 example program, and downloaded only the symbol file for DSP1/C66 via CCS/JTAG, I was able to set and reach breakpoints. However, if I disabled remoteproc’s loading of the exe and attempted to load the entire C66 executable via JTAG, I got an error message ( from memory, remoteproc ID not found). I will reproduce and post up the detail in a separate post… On Tue, May 4, 2021 at 5:20 PM 'Mark Lazarewicz' via BeagleBoard <[email protected]> wrote: Cheng Yes difference between the two Linux is why the E2E wants to know which Linux you running. Walter Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user is using SDK Linux. Perhaps the code examples will help you solve your freeze up. It's possible ARM Linux is using that memory. Looks like the TI PRU expert is very helpful as long as your using the SDK. https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru Sent from Yahoo Mail on Android On Tue, May 4, 2021 at 3:02 PM, Walter Cromer<[email protected]> wrote: I am glad to have helped a little bit. Stick with it. When it clicks and you start really moving forward I think you'll be pleased. Can you share the changes to the Makefile that you made? I'm curious if it might help me. Right now I am reading the ADC every 2.7ms. I'm reading three channels. I include the step id too and check that. I am using switch-case to check the step and put the analog input into the right variable in my code. It might be slighter faster with an if-elseif but I like the neatness of the switch-case and until it causes me timing problems, I'm sticking with it. I am also fairly certain the ADC can be read faster. I have the ADC in one-shot mode and delay before I kick it off again. I've also run this with no averaging, 4 averages, and 16 averages and it makes very little difference in timing for me. Walter On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 [email protected] wrote: Hi Walter, Thank you so much for the reply. I think my setup is exactly the same as what you have (win10 and BBB wireless). That really motivated me to see somebody else successfully run the system with the same setup. I actually made some preliminary progress after two nights brooding and I am able to read out ADC data through rpmsg. Thanks a lot for your tips. I think the problem is still in the makefile and environment. As you mentioned, you are using makefile from PRUcookbook while I started off with TI's built-in makefile. I believe there is a couple of slight difference between Debian system and TI SDK environment which turns out to be critical in compiling. I carefully compared the difference between two makefiles and created one which is close to the makefile in the PRUcookbook. That works like a charm. Next step I also want to explore precise timing and see how fast the adc can run. May I ask what is the speed you are reading out from ADC? Regards,Cheng 在2021年5月3日星期一 UTC-4 上午11:24:23<[email protected]> 写道： I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However, to compile the PRU code and load it I go over to a PUTTY session and use the make files from Mark Yoders' PRU Cookbook (https://markayoder.github.io/PRUCookbook/) . My process is clunky but my programs aren't huge or extremely complex (yet) and this works for me. I don't have and don't want to invest in a debug probe so debugging the PRU code can be a pain and slow. The only option really is to use RPMsg almost like printf to send messages back at key points in the PRU code to let me know where it is executing and what's happening. (Purists and more advanced developers are barfing and laughing at me right now I am sure.) I strongly encourage you to get the Technical Reference Manual for the TI ARM335x and specifically spend time with the Touchscreen Controller chapter. If you need precise timing, you'll want to spend time in the Industrial Ethernet Peripheral chapter too. These are powerful tools once you understand them. Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it. One thing that really tripped me up was their implementation of the __far keyword. GCC doesn't recognize that and I didn't understand what was going on at first. As Mark commented, some people encourage using remoteproc, some encourage using libpruio and some still use the uio. TI supports remoteproc and I expect them to be around so I went with remoteproc. It may have its drawbacks but it is working just fine for me. I can't comment on the other two as I have not tried them. Also, I've found the TI E2E forum's moderators to be patient with me as a neophyte. But the Google group's members do have wider experience. FYI - watch out for how TI puts some register settings that cross nibble or byte boundaries. It can really bite you! Take a look at the STEPCONFIGn registers implementation of averaging to see what I mean. I hope this helps! On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote: <<<My first intention is to post in TI E2E support forums, but it requires a company email to do so. Hello Cheng I want to Help you but it appears my message is lost in translation What it sounds like to me is TI pays these engineers $$ to answer questions and does not want to waste time and $$$ with users that dont follow their well written instructions which say use SDK Yocto Linux on the ARM for this example. For me I start with a working example with instructions and documentation then modifyit If I undertsand correctly you have never had an example working If you like breaking examples and working on projects that ONLY works from a unix script and hides all the details then this is the correct group to to ask questions (-: I suggest you try the example you found following the intructions exactly. if you cant or wont do that switch to DEbian/Cookbook But if you do the latter I suggest don't change things follow the instructions What is interesting is a Linux C application program should work correctly if it was coded generic especially when both Linux variants are for the same chip. Trying to figure out what is different between Linux variants to me is not productive its not my focus for you maybe it is. Perhaps the Linux in the SDK was configured differently which implies it handle PRU slightly different Im not surprised by this. Perhaps you can find what's different that may be a valid approach that works for you and maybe someone can help. I think Dennis gave you a good clue. I will watch the thread hopefully I can be of help should you choose to follow the path E2E and the SDK layed out for you Cheers On Friday, April 30, 2021, 07:52:09 PM CDT, Cheng Chen <[email protected]> wrote: Hey Mark, Thanks for spending time for replying. I really appreciate it. I totally agree with you that one should spend time investigating first. I apologize if they are dumb questions, but I have stuck there for two weeks. I am more a circuit guy and just started picking up Beaglebone as a hobby and potential career expansion. My first intention is to post in TI E2E support forums, but it requires a company email to do so. If this particular .org is not a good place for rookie questions, would you please advise some place for suitable for discussion? Regarding to the documents, are you referring to processor SDK Linux Software Developer's guide? If that is the one, I did follow its instructions, but maybe I missed something. I will go over it again. If that's not the one, which document are you referring to? I also went through PRUcookbook and Exploring BeagleBone by Derek Molly. Not a lot are mentioned regarding this topic. The code is built-in in the Beaglebone Black, this is one of the reasons I am confused why it cannot be compiled. One can also download freely from TI github (https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/). Again thanks for the advice and suggestion. I am very glad that there is such a nice place that I can call for help and I hope after some practice I am also able to contribute here. Regards,Cheng 在2021年4月30日星期五 UTC-4 下午5:09:01<lazarman> 写道： Hello I know the code. It's all explained in the SDK documention. I also like these examples.Your asking questions about an SDK that's supported by Texas Instruments. You do understand this .org group you posted in may contain TI employees but is NOT TI support it's Beagle board Debian. I think if you read the documents you will understand the answers I'm sure you could compile this with some work the sdk instructions talk about This. Hypothetical question ❓If the instructions told you a virtual box build was not supported and not recommended would you use one anyway and then ask the person who told you not too do this why it doesn't work. I'm struggling to be nice in this reply. I remember asking questions as a young engineer that clearly showed I made zero effort to research anything. Then one day I got some really critical replies about my skills. Do some reading then if stuck ask questions Or better yet follow what the sdk instructions suggest. If you found this code on internet and don't have a TI account or are not eligible for ITAR restrictions to download the sdk you have a big problem. I see you have a Gmail account Sent from Yahoo Mail on Android On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen<[email protected]> wrote: Hi all, I am practicing PRU skills through some TI examples. I am playing with PRU_ADC_onChip example and ran into a few questions. I wonder if you can help me with. The nice thing about this example is it has a README.txt with all the procedures. The idea is to use rpmsg to communicate between arm and pru module and read out ADC value. I am using a Beaglebone Black wireless.Here is the basic procedures. FILE STRUCTUREPRU_ADC | |--pru_adc_firmware.c firmware loaded into PRU0 | |--pru_adc_userspace |--pru_adc_userspace.c userspace code that interacts with PRU0 BUILD FIRMWARE & USERSPACE CODE$ cd <PATH_TO_PRU_SW_SUPPORT_PACKAGE>/examples/am335x/PRU_ADC_onChip/$ make clean$ make$ cd pru_adc_userspace/$ make clean$ make My BBB wireless can compile pru code successfully because I installed PRU_CGT compiler. But it is unable to compile ARM code. I think that is because ARM_CCT cross-compiler toochain environment is missing, in another word, I need to install processor-sdk-am335x My first questions is can I install processor-sdk-am335x into Debian system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused about the relationship between this SDK and Debian system. Why is the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. I thought it is supposed to be executed in a cross-compilation environment. I ended up installing processor-sdk-am335x on my linux desktop and compiled successfully. Then I copied the generated file back to BBB wireless. But when I tried to run the program, it shows the following error. Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30 Attached is the excerpt where the problem happened. Could anyone help me with some hints of what is going on here? Much appreciated. struct shared_struct message; /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = "/dev/rpmsg_pru30"; /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to initialize PRU using sysfs interface.\n"); FILE *sysfs_node; char firmware[] = "/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = "PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } fwrite(&firmwareName, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); fclose(sysfs_node); char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = "start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(&start, sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node); /* give RPMSG time to initialize */ sleep(3); ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); exit(EXIT_FAILURE); } } -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/39813de1-fa27-41d7-9422-7ef375ae36b4n%40googlegroups.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ca296f29-c476-45fc-906d-e24595453270n%40googlegroups.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/W5jMCO3fu84/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1105921283.166452.1620163222532%40mail.yahoo.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALJg6gR7CzZygB6x69868BQWx9-vZk6jPe5YFc_ZeNm1-z29Jg%40mail.gmail.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1876066619.342023.1620186193171%40mail.yahoo.com.
