Monday, April 23rd 2018, 5:03pm UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



Date of registration: Jan 30th 2017

Posts: 1


Tuesday, January 31st 2017, 11:12am

Ozone instruction trace on STM32L4xx clobbers CPU RCC registers

Using Ozone 2.22m (and also with 2.22j), I am debugging STM32L471VG and STM32L476
processors, and I observe erratic CPU behavior if the instruction trace or code
profile window is open when resetting the CPU.

I have noticed that if the instruction trace and code profile windows are closed
before CPU download/reset, things work okay. Also, this code was compiled on
Keil uVision, and functions fine.

After CPU reset, I am able to observe what appears to be the cause of the problem by
following these steps:

1. Reset CPU, halting at main.
2. Open the RCC peripheral register window, and observe the list of RCC registers.
3. Open the instruction trace window.
4. Single step into main, once.

I immediately observe that the following registers are clobbered (they turn red,
and contain invalid values):

RCC->CR (0x40021000) gets clobbered with value 0x00000AA3
RCC->CFGR (0x40021008) gets clobbered with value 0x00003FF0
RCC->PLLCFGR (0x4002100C) gets clobbered with value 0x00001550

It seems like Ozone is trying to activate trace on the CPU, and believes it is writing
to GPIOE registers, but in reality is writing to the RCC registers. This
occurred to me after noticing that the STM32F20x GPIOE register base address is
the same as the STM32L47x RCC register base address (0x4800 1000):

Is there any way to manually tell Ozone to use a different trace initialization
configuration for the STM32L4xx chip? The Ozone scripting is not very well
documented yet, and how to do this is not so obvious.

Here are the trace init values that I have used successfully with the Keil uVision
debugger. It seems clear that the value that was intended for address
0x48001008 ended up being written by Ozone to address 0x40021008 :

DEREF(0x4002104C) = DEREF(0x4002104C) | 0x00000010; /* RCC_AHB1ENR: IO port E clock enable */
DEREF(0x48001000) = 0x00002AA0; /* GPIOE_MODER: PE2..PE6 = Alternate function mode */
DEREF(0x48001008) = 0x00003FF0; /* GPIOE_OSPEEDR: PE2..PE6 = 100 MHz speed */
DEREF(0x4800100C) = 0x00000000; /* GPIOE_PUPDR: PE2..PE6 = No Pull-up/Pull-down */
DEREF(0x48001020) = 0x00000000; /*GPIOE_AFRL: PE2..PE6 = AF0 */
DEREF(0xE0042004) = 0x000000E0; /* Set 4-pin tracing via DBGMCU_CR */