How to deal with peripheral interrupts? Use semihosting mode? #16
Labels
question
Further information is requested
Comments
|
Yes, you're correct. In the current cases, the example didn't cover handling interrupts generated by MCU peripherals. The driver code runs on the PC, leaving the MCU core idle, and interrupts cannot be utilized. For more information, please refer to https://interrupt.memfault.com/blog/mcu-peripheral-forwarding |
|
Thanks for the quick reply another question： |
|
It is possible. You can run the firmware with the BLE part on the MCU, storing audio packets in the RAM memory. Using REMCU and a debugger, you can extract the packets from the MCU's RAM, process them, and then write the decoded packets back to the MCU's RAM buffer |
|
As far as I know, generally gdb needs to stop the mcu when processing the mcu memory or peripherals. Is this how REMCU handles it too? Or something similar to gdb live watch? https://sysprogs.com/w/live-non-intrusive-debugging-of-real-time-arm-targets/ |
|
It's an interesting question. I'll check it out and get back to you soon |
|
some interesting discussions:Marus/cortex-debug#943 |
|
I've checked with STM32, ST-Link, and OpenOCD. In the test, the MCU's core didn't stop when the debugger read from RAM memory. However, I can't guarantee this works universally, as it may depend on the specific debugger, MCU, and software components (OpenOCD, GDB server, drivers). |
|
Even if the MCU's core doesn't stop, it's important to note that the core and the inner debugger IP core may share the total memory/peripheral bus |
|
By the way, how should I generate a python interface from an SDK? If done manually, I found that it requires a huge workload. The chip I'm using is atmel SAM4C |
|
I've looked at Preparing nRF51 Drivers SDK for MCU's Peripheral Forwardin. Written in great detail. But it's still too complicated. Can you provide such a "counterfeit" SDK? There are only two functions provided in the sdk: |
Generating a Python interface from an SDK can indeed be a challenging task. Personally, I've automated the process using this repo, but keep in mind that some manual coding is still required. If you're looking for an interpreter, I'd recommend exploring Cling. I've created a tutorial video using it https://www.youtube.com/@RemoteMCU |
While the REMCU SDK doesn't precisely match the provided functions, it does offer equivalent functionality. You can use remcu_store2mem for writing to memory and remcu_loadFrMem for reading from memory. Would these serve your purpose, or is there a specific reason these functions might not be suitable? |
|
I am planning to use remcu under windows, but it seems that the gdb connection cannot be established. How should I debug it? I can't see any log information.I can connect normally using the standard gdb debugging service, but it seems that it cannot work using remcu.dll.
|
|
Have you used this notebook ? Based on the screenshot, it appears that your GDB port is 2331. Can you confirm if this value is passed in the |
I'd like to mention that you can easily change the verbose level using the remcu_setVerboseLevel function |
I'm using the dll from prebuilt_libraries, so I can't confirm that this value is passed in the remcu_connect2GDB. |
I'm using the dll from prebuilt_libraries,I can't see any debug information using the remcu_setVerboseLevel(3) function |
You're correct. You've uncommented the line correctly; I missed that
Perhaps the new version of Jupyter Notebook requires a specific flag for printing logs. Let's try with the console test. Download the directory, move the executable to the dir, and run the executable with the following arguments
if 0x20000000 is your MCU's RAM address |
It seems that openocd is enabled instead of jlink. How should I enable jlink? |
|
My apologies for the confusion. I've updated the repository https://github.com/remotemcu/prebuilt_libraries/tree/master/TEST-TEST_LIB-1-00/Windows_x64. Could you please repeat the steps? `
|
test log Was the test successful? |
|
Run the script directly from the console: LOG: |
|
After the change, the service connection was successful.
|
|
Do you use Python 3? I recall that my examples were originally crafted for Python 2 |
Yes, it is successful |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed that the example did not mention how to handle interrupts generated by MCU peripherals. I think interrupts are not supported in current cases, is that right?
The text was updated successfully, but these errors were encountered: