CRITICAL_REGION_EXIT with Timer and UART interrupts

[rshankle]

Hi All,

I have some code that I'm porting from a Zilog platform over to the nRF52 platform.  The code uses 1 timer and 1 uart.  The goal of the code is to handle RS485 messages.

First, a quick question on the timer, I'm using the following function:

nrf_drv_timer_extended_compare(&TIMER_MB, NRF_TIMER_CC_CHANNEL0, time_ticks, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK, true);

This is from the timer example.  Am I correct that this timer will continue to call interrupts at the specified rate until I specifically call nrf_drv_timer_disable?   

Second part of the question, is I'm using the following to setup a UART:

APP_UART_FIFO_INIT(&comm_params, UART_RX_BUF_SIZE, UART_TX_BUF_SIZE, uart_error_handle, APP_IRQ_PRIORITY_LOWEST, err_code);

(I've run the example and had everything running with putty, a windows serial program using rs232 protocol.)

For my RS485 app I need to toggle when the device can read and when it transmit.  What I'm currently doing is app_uart_close(),  and then redefine the port in the desired mode.

My real question is, I perform "CRITICAL_REGION_ENTER() "  when making changes to the UART and after everything is setup I perform "CRITICAL_REGION_EXIT()"

my problem is for some reason it is triggering a NRF_BREAKPOINT_COND    at CRITICAL_REGION_EXIT() when stepping through in debug mode.  (I'm running in SEGGER Embedded Studio.)

Any thoughts?  Should I be using different functions to toggle the UART setup?

thanks!

Bob

[rshankle]

How do I force my application to run in Privileged mode (even while debugging)?

Curious thing is this isn't the first time it enters and exists the CRITICAL_REGION.  It does so earlier in the code but the UART isn't running at that moment, only the timer.

thanks,

Bob

[wpaul]

It's supposed to be running in privileged mode by default. That why I said "I'm not sure how things ended up this way."

Check the stack trace where the breakpoint happens and see how you got there. Also, dump the registers with the debugger and look at the CONTROL register. If bit 0 is set, that means unprivileged thread mode is enabled. If it's clear, then you're running in privileged mode. If you are running in privileged mode them maybe the problem is something else and I guessed wrong.

-Bill

[rshankle]

Ok, let me track down the CONTROL register in the SEGGER debugger

Would it happen to be apsr->C or xpsr->C    (my limited knowledge of Assembly makes me think that is the carry flags.)

thanks, I'll go hunting in the AM

Bob

[wpaul]

The 'psr' here means the program status register. This register looks a little different depending on whether you're in handler or thread mode. I think you're right that this just the carry flag.

This part of the CPU behavior is part of the Cortex-M4 design, which is from ARM, not Nordic. This manual provides a good overview:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0553b/DUI0553.pdf

I think you want the 'cfbp' display. From what I can find, this stands for Control/Fault/Basepri/Primask. These are all CPU state registers. (See section 2.1.3 in the above document.) I think you need to click the arrow to expand this to get the whole picture. The value 0x00000001 is a little confusing since I don't know exactly which register it's referring to.

(Disclaimer: I use GDB for debugging, which always displays these registers just by saying "info registers.")

-Bill

[rshankle]

thanks I'll look into this.

Bob