[STM32F051K8] No SWD connection after some time ...

[root]

Posted on August 10, 2012 at 09:44

Hello,

I'm working on a custom board around a STM32F051K8. I was playing with it for 2 or 3 days, everything was fine, then without moving it or something, it stopped responding to SWD interface. The previous code is still running in the MCU. The ST Link V2 + ST Link Utilities says not target, JLink manage to stop the core apparently (I have a LED kind of blinking that stops when JLink try to program) but says internal unknown error (the magic one !). At the time it stopped working, I was coding some DMA stuff for PWM. I checked connections, everything is ok. Any hint on what can be wrong ? I know sometimes on STM32F205 when you cannot access the core via JTAG, you can run it in builtin bootloader mode to get access to it, on this board the BOOT0 pin is tied to GND so it would be difficult to do it (I'll try if I can't find another solution). Thomas.

[root]

Posted on August 10, 2012 at 10:14

Hello again,

I tied BOOT0 to 3.3V, entering bootloader (at least not running my code), but still same error messages from the probes :( I don't want to solder a new board before I understand what happened ... Thomas.

[zaurozavr]

Posted on August 10, 2012 at 11:04

Try to erase the chip with a ST-Link Utility.

Run the utility in SWD mode with onboard Reset button pressed, then release it. If connection established  erase the chip.  

[root]

Posted on August 10, 2012 at 14:30

Hello,

Thanks, that made the trick ! (not easy to sodler a wire to an unconnected UFQFN pin 😉 ). Now I need to find why it locked  ... any idea ? Thomas.

[Tesla DeLorean]

Posted on August 10, 2012 at 15:31

DMA, TIM and WFI have been classic failures for ST-LINK as it attempts to wrestle control after reset. I'd recommend trying something like a J-LINK and having it control the SWD and RESET pins. Not sure why the BOOT0 trick didn't help here as it generally offers safe harbour for the debugger to gain control.

Also consider adding some slack time after reset before setting things up, or perhaps checking the state of a GPIO pin to act as a breakout/recover method.

[root]

Posted on August 10, 2012 at 15:45

Hello,

As I already had troubles with that, when debugging I always change my while(1) __WFI(); by a while(1) __nop(); I'd like to send frames so I need a DMA burst over TIM16 ARR and TIM16 OC1 registers. I will plug it back to JLink and plug the RESET pin also in the JLink ... Here is the code I use :

GPIO_InitTypeDef gpio_init; 
TIM_TimeBaseInitTypeDef tim_init; 
TIM_OCInitTypeDef oc_init; 
NVIC_InitTypeDef nvic_init; 
DMA_InitTypeDef dma_init; 
gpio_init.GPIO_Mode = GPIO_Mode_AF; 
gpio_init.GPIO_Pin = GPIO_Pin_8; 
gpio_init.GPIO_PuPd = GPIO_PuPd_NOPULL; 
gpio_init.GPIO_Speed = GPIO_Speed_Level_3; 
gpio_init.GPIO_OType = GPIO_OType_PP; 
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE); 
RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM16, ENABLE); 
GPIO_Init(GPIOB, &gpio_init); 
GPIO_PinAFConfig(GPIOB, GPIO_PinSource8, GPIO_AF_2); 
SYSCFG_DMAChannelRemapConfig(SYSCFG_DMARemap_TIM16, DISABLE); 
// TIM16 DMA on DMA Channel 3. 
dma_init.DMA_PeripheralBaseAddr = (unsigned 
int
) (&(TIM16->DMAR)); 
dma_init.DMA_MemoryBaseAddr = (unsigned 
int
) (m_dmaBuffer); 
dma_init.DMA_DIR = DMA_DIR_PeripheralDST; 
dma_init.DMA_PeripheralInc = DMA_PeripheralInc_Disable; 
dma_init.DMA_MemoryInc = DMA_MemoryInc_Enable; 
dma_init.DMA_PeripheralDataSize = DMA_MemoryDataSize_HalfWord; 
dma_init.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; 
dma_init.DMA_Mode = DMA_Mode_Normal; 
dma_init.DMA_Priority = DMA_Priority_VeryHigh; 
dma_init.DMA_M2M = DMA_M2M_Disable; 
dma_init.DMA_BufferSize = DMA_BUFFERSIZE; 
DMA_Init(DMA1_Channel3, &dma_init); 
tim_init.TIM_ClockDivision = TIM_CKD_DIV1; 
tim_init.TIM_CounterMode = TIM_CounterMode_Up; 
tim_init.TIM_Prescaler = 15; 
tim_init.TIM_Period = 0; 
TIM_TimeBaseInit(TIM16, &tim_init); 
oc_init.TIM_OCMode = TIM_OCMode_PWM1; 
oc_init.TIM_OutputState = TIM_OutputState_Disable; 
oc_init.TIM_Pulse = 0; 
TIM_OC1Init(TIM16, &oc_init); 
TIM_DMAConfig(TIM16, TIM_DMABase_ARR, TIM_DMABurstLength_2Transfers); 
TIM_DMACmd(TIM16, TIM_DMA_Update, ENABLE); 
TIM_Cmd(TIM16, ENABLE); 
TIM_CtrlPWMOutputs(TIM16, ENABLE); 
DMA_Cmd(DMA1_Channel3, ENABLE);

Thomas.

[root]

Posted on August 10, 2012 at 16:26

Hello,

If I remove this code then I can debug and stop core, no problem. Anyway ... I plugged Reset pin in the jlink but did see no difference (unable to debug with this code). In the JLink software it says it cannot reset Coretex-M0 core, is it a JLink limitation or is there something wrong ? I took a screenshot :

https://dl.dropbox.com/u/3574941/no_reset.png

Thomas.

[zaurozavr]

Posted on August 10, 2012 at 16:55

What is your toolchain?

As to my expirience this happens regardless to debug tool (though I prefer J-Link fo a big code due to it  is much faster), but I noticed that sometimes code alignment or just adding some code helps.   

[Tesla DeLorean]

Posted on August 10, 2012 at 18:10

I don't have enough hands-on to speak to the F0/Cortex-M0, but the first VL-Discovery I bricked was doing some cyclic DMA of PWM settings to a TIM. Basically driving a sine-table entry at each update. I got that one back with the BOOT0 trick.

I don't have a clean way to hack a standard debug header onto the discovery series, otherwise I'd check with a couple of different J-Link versions, and U-Links. You might want to clear out or set the OCInit structure completely. I think TIM16 expects idle/polarity/N stuff.

[root]

Posted on September 21, 2012 at 16:23

Hello,

Back on this project ... I still have the exact same problem. I checked I can have a continuous PWM with the same configuration, have non zero values in my DMA buffer ... but again as soon as I trigger a DMA transfer (I want to change both ARR and CCR1), I can't debug it anymore and nothing happens. I soldered a wire on the reset pin on the new board, I'm now waiting for the expoxy to cure (last one broke quiet fast) ... but not even a clue on how to fix this and get it to work. Basically I want to output either a pulse frame (8 peaks with different width), or mimic an UART output at 100kbps (it isn't precise enough using interrupts because the STM32F0 has no interrupt premption mecanism, only priorities). Anyone managed to drive PWM output with a DMA ? Thomas.