I use the ccplex of the nx board to run the bare metal program written by myself. The program wants to implement ivc communication with freertos in the r core. But But R-core freertos aborts unexpectedly when I run the program. For freertos to run, does the A core need to send some characteriastic information to the R-cortex, such as heartbeat?
run the bare metal program written by myself
Do you mean you’ve skipped Linux, and run some raw bin code?
Generally, IVC between CCPLEX and SPE needs some low level module support. You may have to implement the full stack by yourself if my guess is true.
Yes, your understanding is true. I’m not sure what implementing a full stack means. Could you be more specific? Thank you.
It may be a little complicated.
You can take a look at Kernel communication with spe - Jetson & Embedded Systems / Jetson TX2 - NVIDIA Developer Forums
Though it may be a little outdated, the basic framework should be same.
In SPE side, you can also take a look at “rt-aux-cpu-demo-fsp/drivers/ivc-channels.c”, which responds the message from CCPLEX and does some initializations.
Thanks for your reply!
Do you mean I need to follow the code of kernel/nvidia/drivers/platform/tegra/tegra-aon.c and kernel/nvidia/drivers/platform/tegra/tegra-aon-ivc-echo.c to implement a program that can communicate with rt-aux-cpu-demo-fsp/drivers/ivc-channels.c? In fact, I did this before, but the running of freertos always stops unexpectedly. Do I need to implement some additional modules to keep freertos running properly?
Do you mean I need to follow the code of kernel/nvidia/drivers/platform/tegra/tegra-aon.c and kernel/nvidia/drivers/platform/tegra/tegra-aon-ivc-echo.c to implement a program that can communicate with rt-aux-cpu-demo-fsp/drivers/ivc-channels.c?
Yes. That’s the basic steps to start.
In fact, I did this before, but the running of freertos always stops unexpectedly. Do I need to implement some additional modules to keep freertos running properly?
Can you try to debug where SPE firmware hangs? We have not tried SPE without Linux running, and may only provide very limited support for your case.
- Without CCPLEX communication with SPE, can SPE firmware runs correctly?
- You can add some logic in CCPLEX as something like command to read/write registers, and simulate driver behaviors, and check which command results in SPE hang.
- Keep debugging and find out the root-cause.
I see. The SPE firmware hangs on a printf statement in the interrupt handler ccplex_ipc_irq the SPE receives SMBOX_IVC_NOTIFY (0x0000AABB) from ccplex, and it was supposed to print “data = SMBOX_IVC_NOTIFY\ r\ n”, while the serial port only sees “data = SMBOX_IV”.
the print code may not be good enough to locate the error.
You may still have to check which command hangs the SPE firmware.
At present, I only have this way to visualize the positioning problem. Do you have any other more reliable ideas to share with me? Thank you!
No better way for debug.
I just want to remind you that print code can only be used as a reference, and full trusty of print log may lead to wrong direction, since UART output may be delayed.
My suggestion is still to debug firmware step by step.
- Make a runnable firmware and confirms it works as expected.
- Add more functions, one by one, or communicate with CCPLEX with messages one by one. Once SPE hangs, you may know where the issue happens.
- print can be used as a reference to make sure your code works.
Back to your problem, does the SPE hangs from beginning, or after some communications from CCPLEX crashes SPE firmware?
Use dbgprintf_isr in ISR, and make sure ivc_ccplex_carveout_configure is correctly called first.
Thank you for your enthusiastic help, I will give these suggestions a try.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.