Issue: Monitoring UART using the Peripheral Monitor in LPC Xpresso makes UART unusable

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issue: Monitoring UART using the Peripheral Monitor in LPC Xpresso makes UART unusable

170 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by rhoukes on Thu Oct 16 05:51:36 MST 2014
Basicly the title explains it all. I ran into it the problem while trying to work with the UART peripheral on a LPC1763. I use the Peripheral Monitor in LCP Xpresso to see if all the registers are set to what I expect. With another peripheral that all went well. However when debugging the UARTs available, monitoring the UART perihperal complety makes the UART stop working. If the UART peripherals are not monitored the UART works fine without issues. The UART recieves and send bytes with no issues.

The debug link it provided using an LPC-Link debugger.

I do not know it monitoring was the UART peripherals was impossible to begin with. On the other hand I might have ran into a quite odd bug.

Steps to reproduce:

1. Enable the UART
2. Montitor the UART using the Peripheral Monitor
3. Try using the UART and find out it does not work when monitored.
0 Kudos
1 Reply

151 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MikeSimmonds on Thu Oct 16 07:50:09 MST 2014
I have seen this and similar before. The reason [obvious in hindsight -- kicks self] is the the debugger
*has* to read the registers in order to display them.
With some peripherals (including the UARTS), reading, say, the received character buffer will
*immediately* change certain status bits and even IRQ pending flags perhaps even if the display does
not reflect this (due to the order in which the registers are read?).

Then, when your code continues, the staus bits, received character etc. have gone or been changed.

I had hoped that access to these and other registers by the on-chip debug circuitry would somehow
have special (magic) privillege so as not to alter the hardware state [because we want to observe
or verify, not change *anything*] but I seem (by observation) to be sadly dissappointed.

Anyway, that may answer your question.

HTH, Mike.
0 Kudos