Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to selectively refresh registers in SVD viewer (support readAction) #804

Open
AndreySmirnov81 opened this issue Jan 17, 2023 · 4 comments

Comments

@AndreySmirnov81
Copy link

Reading from some registers has a side effect. For example, reading from USART_DR resets the USART_SR.RXNE bit.
It would be nice if it would be possible to selectively refresh only the necessary registers and peripherals, as well as prohibit automatic refresh.
Something like this:
изображение

@haneefdm
Copy link
Collaborator

Can you share this SVD file? In recent versions of SVD Specs, there is a description on register/field to say what happens when a read is performed...

image

https://www.keil.com/pack/doc/CMSIS/SVD/html/elem_registers.html#elem_cluster

This (like a ton of other things) was added to the spec much later (after this SVD parser was written). When readAction exists, we are never supposed to read that address. This was obviously not implemented. Question is, does your SVD file specify this? If so, we can see if we can add this attribute support.

Note that if even one field is marked as having a side-effect, it will affect the entire register.

I am not considering adding the 'Auto' button. I would rather implement readAction

@haneefdm
Copy link
Collaborator

Note that this should actually be considered a bug in the device. ARM provides a facility to know if the read/write request is coming from the debug port or from someplace else. This can be used to avoid reading registers that have side effects. Trust me, I have implemented this for our devices... so such registers are safe even if they are accidentally read by a debugger (we have multiple debuggers, and not all handle this well) -- Especially when reading memory in bulk.

Besides your UART regs, there are FIFO pointers and a variety of register types that have side effects but they only make sense when accessed via the CPU/DMA

@AndreySmirnov81
Copy link
Author

AndreySmirnov81 commented Jan 18, 2023

Thank you for the response.

My SVD file does not contain the readAction attribute. But if necessary, I can add it.
STM32F100.svd.txt
(taken from https://stm32-rs.github.io/stm32-rs/stm32f100.svd.patched and slightly modified so that the SVD viewer accepts it)

In my microcontroller, reading the USART_DR register by the debugger has a side effect.
It would be great if support for the readAction attribute was added.
However, I think that for each register with readAction, a separate Refresh button will not be superfluous.

@haneefdm haneefdm changed the title Add the ability to selectively refresh registers in SVD viewer Add the ability to selectively refresh registers in SVD viewer (support readAction) Mar 13, 2023
@IZBH
Copy link

IZBH commented Jun 18, 2024

Note that this should actually be considered a bug in the device. ARM provides a facility to know if the read/write request is coming from the debug port or from someplace else. This can be used to avoid reading registers that have side effects. Trust me, I have implemented this for our devices... so such registers are safe even if they are accidentally read by a debugger (we have multiple debuggers, and not all handle this well) -- Especially when reading memory in bulk.

Besides your UART regs, there are FIFO pointers and a variety of register types that have side effects but they only make sense when accessed via the CPU/DMA

I encountered the same issue and I hope to fix this error on the device. Regarding the tools provided by ARM to determine if the read/write request is coming from the debug port or elsewhere, could you provide me with some documentation links for reference?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants