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.
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…
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
Hi Walter,
Sorry for the late reply.
The most important part I modified for TI’s makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly’s version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well.
start:
ifneq ($(PRU_DIR),)
@echo write_init_pins.sh
@$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
@echo “- Starting PRU $(PRUN)”
@echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
ti-mct-heap-check -c
sudo mjpg_streamer -i “input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne ‘//(video\d+)/name/ && print $$1’)
–filter ./$(TARGET)$(EXE)” -o “output_http.so -p 8090 -w /usr/share/mjpg-streamer/www”
else
./$(TARGET)$(EXE)
endif
Regards,
Cheng
Walter Cromer <walterc@edenconceptsllc.com> 于2021年5月4日周二 下午4:02写道：
Hello Cheng
I learned a few things this weekend I thought I would share
The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10
You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development
The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK
BBB is also supported
My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7
The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion
The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that don’t care about details
they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare.
So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you.
If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset.
Mark
Hi Walter,
Sorry for the late reply.
The most important part I modified for TI’s makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly’s version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well.
start:
ifneq ($(PRU_DIR),)
@echo write_init_pins.sh
@$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
@echo “- Starting PRU $(PRUN)”
@echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
ti-mct-heap-check -c
sudo mjpg_streamer -i “input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne ‘//(video\d+)/name/ && print $$1’)
–filter ./$(TARGET)$(EXE)” -o “output_http.so -p 8090 -w /usr/share/mjpg-streamer/www”
else
./$(TARGET)$(EXE)
endif
Regards,
Cheng
Walter Cromer <walterc@edenconceptsllc.com> 于2021年5月4日周二 下午4:02写道：
Update AM335x SDK evaluation
Sucess!! rebuild kernel sources in VBOX next will test my LInux on ARM on a board with RPROC drivers and lastly revist CCS and JTAG in Ubuntu VBOX as an option I prefer CCS on Windows but do recall CCS Linux is needed for Linux debugging
Final eval steps use CCS to measure PRU instruction timings following the Labs
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
mark@mark-VirtualBox:~/ti-processor-sdk-linux-am335x-evm-06.03.00.106/board-support/linux-4.19.94+gitAUTOINC+be5389fd85-gbe5389fd85$
Hello Cheng
I learned a few things this weekend I thought I would share
The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10
You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development
The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side
I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK
BBB is also supported
My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7
The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended )
CCS DOES NOT require linux to load and debug PRU
For those that want to learn ARM TI RTOS Win 10 is required to build
The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code
The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you.
I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route.
Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion
The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost.
The approach in this group is wonderful especially for Linux App types that don’t care about details
they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare.
So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you.
If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset.
Mark
Hi Walter,
Sorry for the late reply.
The most important part I modified for TI’s makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly’s version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well.
start:
ifneq ($(PRU_DIR),)
@echo write_init_pins.sh
@$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
@echo “- Starting PRU $(PRUN)”
@echo start > $(PRU_DIR)/state
else ifeq ($(PROC),tidl)
ti-mct-heap-check -c
sudo mjpg_streamer -i “input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne ‘//(video\d+)/name/ && print $$1’)
–filter ./$(TARGET)$(EXE)” -o “output_http.so -p 8090 -w /usr/share/mjpg-streamer/www”
else
./$(TARGET)$(EXE)
endif
Regards,
Cheng
Walter Cromer <walterc@edenconceptsllc.com> 于2021年5月4日周二 下午4:02写道：
Mark makes some excellent points. I started developing C on the ARM side under Linux before needing to start using PRUs. I had not spent much time in the TRM while working on the host side because I didn’t need to. It really bit me until I did. Once I really dug into the TRM and started to understand the SOC at a hardware level, things began to progress much better and faster. And, going through the PRU Optimizing C/C++ Compiler manual and PRU-ICSS/PRU_ICSSG Getting Started Guide on Linux helped too. What DID NOT HELP was that TI has not finished moving the wiki pages over to a new resource but at least they made them available for download.
And, finally, this group of people have been awesome to help!
Hi Mark,
Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that.
I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now.
I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help!
Regards,
Cheng
在2021年5月8日星期六 UTC-4 下午7:52:41 写道：
HI Cheng
I have two Beaglebone White and the am335x SK both have JTAG on the board so no soldering.
The key is to follow the labs 1 to 3 only dont use any RPMsg examples
The other key is the PRU gel script is crucial there is a typo error in the instructions about correct .gel file name and how to execute it
I used CCS 6.0 win 7 and CCS 10 on windows 10
Id be glad to help if I can
The power of the CCS/JTAG is reading memory locations and finding crashes quickly its worth the learning curve
Any issues please ask but tell me your CCS version
What I dont like about the PRU tutorials is all use Linux interaction as in interrupts and they assume SDK linux not Debian
Its some work but you could use Windows to create a SDK linux SD card for JTAG if problems
I have several jtags one is USBV2 and I have yours I also have two BBB but even being EE I dont solder
Let me know be glad to help trust me after you master CCS/JTAG you will be very happy and have an awesome tool in your belt
Mark
Hi Mark,
Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that.
I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now.
I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help!
Regards,
Cheng
在2021年5月8日星期六 UTC-4 下午7:52:41 写道：
Hello Walter and Cheng
I spent 2 hours total doing following
1)Created Ubuntu 16.04 LTS Dev Box using VBOX on Win 7
2) Created SDK linux SD card using image writer on Windows booted Linux on Beaglebone White
3) Rebuilt kernel sources created images of customized kernel and replaced these on SD card
I have a full development environ Now !!!
Next step add a kernel driver I wrote and understand how use the OCP shared RAM to get large amounts of data from PRU to linux
This thread doesn’t appear to appear on the revamped beagleboard forums… correct me if I’m wrong…
Should it be added retroactively or should we create a thread on the new forums with a link to this?
Thanks!