Debug problems with STM32F030 - Page 1
Forum section: electronics / general

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 26, 2017, 10:23:43 pm
content: Hello.I'm trying to debug code on STM32F030.SWD debug wire is enabled. All updates are done, etc...I can get into debug mode!The problem is that the code blocks whenever a HAL_Delay() occurs.I think the problem is related to systick timer, because the program counter does not move from there.I do not know how to solve this problem. I already tried several things, but I did not find anything concrete about someone who had this problem.I'm using SW4STM32, ST-Link utility and ST-link V2.Look at this picture (ignore the 'expressions' tab)The code is very simple, as you can see here.PS: I've never had an answer with solutions in the ST forums (several past experiences). So I'm putting this post here because it seems to be much more frequented and capable than the ST forum itself.

author: ataradov
author_rank: Super Contributor
timestamp: March 26, 2017, 11:29:48 pm
content: Can you actually step to that HAL_Delay(100)? Your call stack seems to indicate that this HAL_Delay() is called from Error_Handler(), called from MX_ADC_Init().Try single stepping until you hit the first HAL_Delay() call.

author: mubes
author_rank: Regular Contributor
timestamp: March 27, 2017, 06:37:56 am
content: Do you have WFI enabled? I have had really trouble doing debug with that enabled on a L1.....YMMV.Dave

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 27, 2017, 07:28:02 pm
content: Now I get this crap again...I removed the 2 lines in the startup tab.I also changed the C optimizer compiler to "O None".I enabled the WFI, but the problem remains the same ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 27, 2017, 10:29:24 pm
content: I'm definitely not getting any breakthrough.I created a new, simple project, to just blink an LED.I can use ST-Link to program without problems ... but I can not debug.Here is the project.https://meocloud.pt/link/598784ec-fa1d-42d8-af76-7cb16e4d0636/debug.rar/What am I doing wrong?At work I'm using a setup very similar to this, but with an STM32F302. The debug runs smoothly

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 08:43:24 am
content: I think the problem is with the programmer.I'm using one of these clones.At work I tested it and does not work either.Can someone confirm me if you can debug with a programmer like this?The ST-Link I'm using at work has a different firmware version as well.CLONE

author: MrBungle
author_rank: Unknown
timestamp: March 28, 2017, 09:06:19 am
content: Do you have a Nucleo or Discovery board that you can use?They come with a genuine STLINK on the board.Never really understood why people buy clone STLINK when a Nucleo/Discovery board costs so little

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 09:44:52 am
content: At work I use a Nucleo board, and the in board ST-Link. It works!But in house for my personal projects I try to give a shot with this clone.

author: gnif
author_rank: Unknown
timestamp: March 28, 2017, 09:48:28 am
content: Did you configure and enable the SysTick IRQ? See:http://www.micromouseonline.com/2016/02/02/systick-configuration-made-easy-on-the-stm32/

author: tatus1969
author_rank: Super Contributor
timestamp: March 28, 2017, 09:58:11 am
content: it can also be hardware related. can you post the related circuit? try reducing the interface speed. i am using st-link and segger debuggers, no problem once set up correctly. also keep in mind that your code is able to interfere with debugging, like gpio configuration (you can disable swi ports). validate your cpu clock speed. try skipping pll setup. avoid power saving cpu states. disable all code optimizations.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 10:05:34 am
content: Hello tatus!In this case I only have a very simple code to blink a LED.But now I have pretty sure that the problem is related with this crap of St-Link clones...Sooner, I'll take an original ST-Link home and do the same tests.Because here at work I'm having the same problems that I have at home with the clone. So the problem must be the programmer.With the original ST-Link I have zero problems.

author: technix
author_rank: Super Contributor
timestamp: March 28, 2017, 12:42:55 pm
content: In the interim, if you have any Cortex-M MCU that have built-in USB, you can try load the CMSIS-DAP firmware into it, which will make it function as an OpenOCD-compatible JTAG+SWD dongle.In fact you can even load this ST-Link clone with CMSIS-DAP and it would work a lot better.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 01:32:43 pm
content: In short...* I connect the original ST-Link and got the same result.* I started using the same startup commands and can now can enter debug mode.* I did not use PLL.* The code runs normally until it find a HAL_Delay.* In the image you can see thattickstartis zero, after going through HAL_GetTick ().* The problem is inHAL_GetTick().* All the clock options are well configured (all generated by CubeMx).* If I compile and program with st-link the code runs smoothly.Strange... because I've done the same with a STM32F302, and the debug works fine.Can the generated files by the CubeMx have any error?Can this error cause problems only in debug?

author: mubes
author_rank: Regular Contributor
timestamp: March 28, 2017, 01:39:53 pm
content: Inability to complete erase is usually psu problems. Check your supplies and don't rely on the programmer giving you enough juice. The little programmer you've got will work fine but consider upgrading to black magic firmware on it.Check what is programmed in the chip is what you think is there!Dave

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 01:50:29 pm
content: Quote from: mubes on March 28, 2017, 01:39:53 pmMy circuit is powered externally.In the PCB I only have soldered the MCU, the power regulation, the LED and the header for programming... nothing else is connected.

author: tatus1969
author_rank: Super Contributor
timestamp: March 28, 2017, 06:04:35 pm
content: how does the jtag/swd circuit look like? also the jtag-only ports may be relevant, even if you use swd.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 28, 2017, 06:54:04 pm
content: I got it!In the SW4STM32 forum I received a suggestion that completely solved the problem!For future reference, I leave here these images.Now the code already passes through HAL_Delay ()What situationQuote from: technix on March 28, 2017, 12:42:55 pmCan you give me more information about this so I can read?Thank you all!

author: thm_w
author_rank: Super Contributor
timestamp: March 28, 2017, 10:03:20 pm
content: Good you solved it, and found out the clone stlinks are not "crap".You can load with j-link fw as well as was found out on this forum.Quote from: MrBungle on March 28, 2017, 09:06:19 amIts ~$20 for a nucleo board, vs $2 for a clone. Not to mention the clone st-links are smaller, shielded with metal (no sharp exposed pins), come with a jumper cable, and have the pins clearly labeled (my nucleo board is unlabeled).

author: technix
author_rank: Super Contributor
timestamp: March 29, 2017, 03:53:25 am
content: I think that ARM have documentation about CMSIS-DAP and the code on their website. You may need to download Keil uVision to configure and compile it, but as an interim measure the free version should work.

author: MrBungle
author_rank: Unknown
timestamp: March 29, 2017, 07:47:51 am
content: Quote from: thm_w on March 28, 2017, 10:03:20 pm$20 is still cheap, If the 10x price difference was an order of magnitude larger($200 vs $20) I'd side with you.Anyway, I don't buy Nucleo's for the ST-Link, the $18 (including next day delivery, no waiting 3-4 weeks from China) is for the dev board.The removable ST-Link V2-1 hanging off it is just a nice bonus.I guess I could look at it as a $16 Dev board with a $2 ST-Link attachedHorses for courses