cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F303K8, write to SYSCFG register has no effect

Ozone
Principal III

I got another strange issue with a STM32F3, as usual related to DMA.

The problem relates to an "old" DAC / DMA example I tried to port to a different MCU.
The original is called "DMA_RAM_DAC", and is part of the V1.1.0 firmware package for the F303 discovery board.
(.../STM32F3-Discovery_FW_V1.1.0/Project/Peripheral_Examples/DMA_RAM_DAC)
Building and running it on this target, it works fine.

However, my actual target hardware is the F3 Nucleo32. This board has a STM32F303K8T, instead of the 'huge'  STM32F303VCT on the F3-Discovery.
The relevant difference here is, the mentioned example uses DMA2 channel3, which does not exist on smaller devices like the STM32F303K8. According to the reference manual, the relevant DMA request can be mapped to DMA1, by setting corresponding bits in SYSCFG (RM0316 Rev.10, page 267, 269).
To do this DMA request mapping, bit 13 in SYSCFG->CFGR1 needs to be set.

And here is were the problem starts.
No attempt to write to this register seems to have any effect, being it (SPL) library calls, register access (SYSCFG->CFGR1), or directly accessing it by address.
The reference manual, IDE register-map file, ST's *.SVD and the toolchain agree on 0x40010000 for SYSCFG, with CFGR1 at offset 0.
I checked the instructions and the core register values in the debugger, and everything looks ok.
Only the final write access (str r2, [r3]) has no effect, but causes no errors either.

SYSCFG->CFGR1 |= 0x00002000;
    2300        movs r3, #0
    F2C40301    movt r3, #0x4001
    681A        ldr r2, [r3]
    F4425200    orr r2, r2, #0x2000
    601A        str r2, [r3]

Consequently, there is no output from the DAC.
Replacing all instances of "DMA2" with "DMA1" and adding the access to SYSCFG are the only changes to the source code of the original project (and changing the target MCU, of course).

Accessing the DAC via timer and interrupt work fine, this is not the issue either.
And when stepping beyond the DMA enable, all the expected flags are set, and no error flag.
Configuring a DMA TC interrupt for testing, it doesn't fire either.

The toolchain / IDE used is SeggerES (Embedded Studio), with the latest being V8.22a.
The build for the F3-Discovery target was done with SeggerES as well, so there seems no inherent problem.
Trying Segger's freestanding "Ozone" debugger (unrelated to my moniker !) revealed no further insights.
The only issue I see with SeggerES so far is that the SYSCFG peripheral registers CFGR3 and CFGR4 are missing in the debug view.

I am overlooking something here, or is anybody aware of issues related to accessing SYSCFG ?
All bits in SYSCFG->CFGR1 are marked as "rw" in reference manual, is that correct ?
Otherwise i'm running out of ideas.

1 ACCEPTED SOLUTION

Accepted Solutions
Peter BENSCH
ST Employee

Is it possible that you forgot to enable the SYSCFG peripheral clock?
If the SYSCFG clock is not enabled, register writes can appear to succeed but have no effect.

RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN;

Regards
/Peter 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

2 REPLIES 2
Peter BENSCH
ST Employee

Is it possible that you forgot to enable the SYSCFG peripheral clock?
If the SYSCFG clock is not enabled, register writes can appear to succeed but have no effect.

RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN;

Regards
/Peter 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

You are right, enabling SYSCFG in the first place helped.
I don't know why I assumed it was on automatically, I probably mixed that up with SCB ...

And I wonder why there is no error reaction.
I remember quite well that Cortex M devices from other vendors throw hardfaults in this case.