configuration registers used in software work-arounds

[astella]

To the kind attention of Nordic support team,

Let's take this as an example:

static inline void usbd_errata_187_211_begin(void)
{
NRFX_CRITICAL_SECTION_ENTER();
if (*((volatile uint32_t *)(0x4006EC00)) == 0x00000000)
{
*((volatile uint32_t *)(0x4006EC00)) = 0x00009375;
*((volatile uint32_t *)(0x4006ED14)) = 0x00000003;
*((volatile uint32_t *)(0x4006EC00)) = 0x00009375;
}
else
{
*((volatile uint32_t *)(0x4006ED14)) = 0x00000003;
}
NRFX_CRITICAL_SECTION_EXIT();
}

My question is: what is the meaning of those registers? Is there documentation available? Should it be the case, can you please point me out to that?

My concern is just check if somehow, those configurations register get corrupted. And I d like to check all of them if possible.

Best regards

[Karl Ylvisaker]

Hello,

My question is: what is the meaning of those registers? Is there documentation available? Should it be the case, can you please point me out to that?

You are correct that there exists some undisclosed internal registers that are not documented in the Product Specification. There is no need for any modification of configuration of the undisclosed registers. Any attempt to interfere with these registers might lock up the peripheral and/or cause undefined behavior.

In the specific case you mention, this is the implemented workaround for Errata 187 for the nRF52833. 

My concern is just check if somehow, those configurations register get corrupted. And I d like to check all of them if possible.

We thoroughly test all the functionality of the peripherals during development, so this is not likely.
What makes you suspect that your configuration is corrupted? What behavior are you seeing?
Are you encountering any errors or resets of your device at runtime?

Best regards,
Karl

[astella]

Hi Karl, thank you for replying. The idea was just to check in advance all possible/existing configuration registers relevant for USB. Just in case they get corrupted for some unknown reason. But that is ok, we will strictly adhere to sdk examples and check only configuration registers that are used in your workarounds. Best regards