SVD Viewer appears not to respect <readaction> SVD attributes

[sephamorr]

The <readaction> SVD attribute (https://arm-software.github.io/CMSIS_5/SVD/html/elem_registers.html), specifies side effects for reading a register, specifying that "Debuggers are not expected to read this register location unless explicitly instructed by the user.".

For example, reading the RXDR register in STM32 SPI peripheral (RM0433 as an example) removes this value from the RX FIFO, changing the program execution that depends on reading that data. This register should be marked <readaction>modifyExternal</readaction> in the SVD, but this property is not respected by cortex-debug even when present.

Other debuggers I have used will require a separate double-click on a <readaction> tagged register.
I'm taking a look to see where might be the right place to implement this, but I am not familiar with TypeScript and this codebase, so help would be appreciated.

(Note that there's a small chance that I've misdiagnosed my issue, but I'm pretty certain this is why my microcontroller code is failing.)

[haneefdm]

ARM introduced a whole bunch of such attributes over time. Didn't exist when this parser was written. I don't remember the changes being in release notes but there they are. They also added the 'readAction' on a part of a register (fields), so you can have certain parts okay but other parts having side effects. We may have to mark the whole register as special if something inside is special

Yes, registers with side effects (especially FIFOs, clear-on-read, etc.) are always problematic. In my past life I designed HW and was very careful to make sure that memory access coming from a debugger, we would guard the state of the register. Not everyone does that. Oh well!

I am not sure that we can do a double-click UI action on such a register but we can mark such registers as non-readable and then use a right-click menu to read/update. You can always get the value from the gdb console -- or using the watch window.

I will get to this eventually, but we may do it in two parts. 1) prevent reads first, 2) take UI actions later.

[haneefdm]

Closing this in favor of #804