STM32, Peripheral register's concents not shown

[R2COM]

So I am configuring TIM3 for specific operation, and a function is setting some of its registers (CR2, CCMR1, SMCR etc); however, when i put breakpoint right before the function exit in order to check register contents during debug I see that debugger is not showing any of the bits being set. It just shows all contents as 0.

On the attached pictures i show where my breakpoint stops on the code, as well as the snapshot of Hardware Registers tab and the added watch tab for registers, all reads zero.

why is that?

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This could happen if the register addresses were loaded incorrectly, or if the tool used for accessing the device (e.g. OpenOCD) fails to access the memory.

Please try locating one specific register that should be non-zero and verify that its address shown in the Hardware Registers window matches the documentation (or the address in the code).

Then try evaluating “*((int *)0x<address>)” in the Watch window. If you are using OpenOCD, please try running “mon mdw 0x<address>” in the GDB Session window. Then check if the output is still zero and if the OpenOCD window shows any warnings errors.

If the values are still zeroes, please try reading the register programmatically into a volatile variable (e.g. volatile int test = *((int *)0x<address>) and check its value. If it is also zero, the issue is not caused by the debugging logic and the registers do actually have a value of zero (e.g. if you have not enabled the corresponding peripheral’s clock).

[R2COM]

As for checking, the TIM3 has following address according to manual:
<table class=”NormalTable”>
<tbody>
<tr>
<td width=”266″><span class=”fontstyle0″>0x4000 0400 – 0x4000 07FF </span></td>
<td width=”88″><span class=”fontstyle0″>1 KB </span></td>
<td width=”177″><span class=”fontstyle0″>TIM3</span></td>
</tr>
</tbody>
</table>
I am attaching snapshot with address info as well as register layout, you can see that TIM3 there starts at right addrexx 0x40000400,
However, the register scheme shows that it also has bits after bit 7 , but according to ref. manual TIM3->CR2 only has up to bit 7 used, others reserved. Not sure if its relevant or result of some copy-paste (maybe copy paste from CR2 of TIM1, who has those bits as i showed in another snapshot).

but, at least i can see that address of register is correct.

I also evaluated the command mon mdw 0x40000400 in debug console, and attaching what i got, i think i got all zeros as well.

then I did this in program code:

volatile int test = *((int *)0x40000400);

and during break, pointing cursor to “test” shows 0.

so..at this point its 100% not debugging related issue then…I assume?

Attachments:

You must be logged in to view attached files.

[R2COM]

by the way, why register scheme for CR2 is looking like its CR2 of TIM1 rather than CR2 of TIM3?

[support]

Thank you for confirming your support status.
It looks like the register address is indeed correct. If the “test” variable has a value of zero after reading the data at 0x40000400, VisualGDB is indeed working as expected and the problem is caused by something else.

The bit field definitions inside each register are computed by our BSP release logic based on parsing ST’s header files and do not reflect minor differences between peripheral instances (e.g. TIM3->CR2 vs TIM1->CR2). You can override this by locating the peripheral register definition file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs (see the MCUDefinitionFile element in the stm32.xml file in the project directory) and manually editing the register definitions you would like to change.

[R2COM]

alright, the TIM3 really was not clocked properly, now the debug register shows up right.

 

regarding the reg scheme, id like it to be fixed by you guys maybe on some of the next updates… not that i cant live without that feature, its just…if its there already, it would be nice to have it implemented fully and up to hardware spec.

[support]

Good to know it works. We suggested checking the peripheral clock in our first reply.

Regarding the registers, unfortunately it is not realistic to manually verify hundreds of registers definitions in hundreds of ST’s devices, hence we have to rely on an automated process of computing them, that has its limitations. If ST released better SVD files with detailed subregister definitions, we would gladly pick them up and use them instead of the header file parser. Please feel free to suggest that to ST.

[Author]

Posts