What's MRI_THREAD_MRI meaning? about mri HOT 6 CLOSED

This is like the thread awareness debugging. We just finish NuttX thread awareness debugging, can we reuse that code?

I wouldn't be surprised if it is similar.

from mri.

Got the answer, let's close now.

from mri.

Normally MRI is meant to be used as a kernel debugger. It can debug and step through almost all code in the system and it does this by running at the highest priority level in the system.

In the case of Arduino, we wanted to use the USB stack as the communication channel which meant keeping most of the RTOS running while MRI was debugging. This means that MRI is actually being run in ARM's thread mode at the lowest priority level and can only debug other 'user' mode threads. It can't debug any ISRs which run in 'handler' mode so no device or kernel debugging is possible. Arduino's ThreadDebug Library

Those MRI_THREAD_MRI sections are there because in that case, that work isn't done by the MRI core but must be done from the user mode portion. I don't really expect others to use that model so I don't really document it. It seems to work in the Arduino code base but I am not 100% confident in the implementation yet.

from mri.

Thanks, this information is very useful to support the complex transport(USB/WiFi) other than UART.

from mri.

Yes it is good for that, at the cost of not being able to debug things which run at the same priority level as the USB/WiFi stack or higher.

On my current robot, I use the BLE stack as the communication channel back to GDB. To allow the BLE stack to run while MRI has a program halted for debugging, I need to run MRI at a priority level of 6 on a Cortex-M4F where priority level 7 is the lowest priority. This means that I can only debug ISRs running at that lowest level (level 7). Any ISR running at a higher priority will not be debuggable by MRI. In this scenario I am running MRI at a priority level lower than 0 but still not in thread mode so I don't need to set MRI_THREAD_MRI macro to a non-zero value though.

The big thing that changes when you set MRI_THREAD_MRI is that you will need to write code which can fetch the register context from wherever NuttX has stored it when it was halted for debugging. In the Arduino case, I freeze the halted thread in the RTX RTOS (and usually most of the other threads as well) and then manually probe RTX's data structures to find the register context and use it to build up the context record required by MRI before calling mriDebugException().

from mri.

Yes it is good for that, at the cost of not being able to debug things which run at the same priority level as the USB/WiFi stack or higher.

On my current robot, I use the BLE stack as the communication channel back to GDB. To allow the BLE stack to run while MRI has a program halted for debugging, I need to run MRI at a priority level of 6 on a Cortex-M4F where priority level 7 is the lowest priority. This means that I can only debug ISRs running at that lowest level (level 7). Any ISR running at a higher priority will not be debuggable by MRI. In this scenario I am running MRI at a priority level lower than 0 but still not in thread mode so I don't need to set MRI_THREAD_MRI macro to a non-zero value though.

The big thing that changes when you set MRI_THREAD_MRI is that you will need to write code which can fetch the register context from wherever NuttX has stored it when it was halted for debugging. In the Arduino case, I freeze the halted thread in the RTX RTOS (and usually most of the other threads as well) and then manually probe RTX's data structures to find the register context and use it to build up the context record required by MRI before calling mriDebugException().

This is like the thread awareness debugging. We just finish NuttX thread awareness debugging, can we reuse that code?

from mri.