ST-Link Utility Behaves Different from IAR Debugger

[Rogers.Gary]

Posted on December 19, 2014 at 22:58

Hello:

I am using an ST Discovery Board (MMB997C) and programming / debugging it with IAR Workbench. It has the STM32F4 processor. I have a small external PCB connected to the Discovery board using the SPI lines that has an SPI controlled device. (a PGA112) When I run the IAR debugger, which flashes and runs the Discovery STM32F4. It operates correctly and as expected; both the SPI device and debug output. Upon initialization the PGA is set to a 2, and then the gain control loop increments the SPI controlled amplifier to the correct level - which is clearly visible as I observe the output of the gain amp. I then STOP the IAR debugger. Then, I open the ST- Link utility and connect to the Discovery board. I can either reload the firmware or not, it makes no difference. In any case, it's exactly the same firmware I just ran in IAR. I then select ''ST LINK->Print via SWO Viewer'' and click the START button. I see all of the expected debug output exactly as I do from the IAR debugger. What is bizarre is that, the SPI control does not appear to work when using the ST LINK Utility. The printout is clearly showing the same statements, it is operating in the control loop. The very first thing I would expect it to do is set the PGA gain to a value of 2. It just seems to ignore any SPI commands while running in ST-Link utility! So far, I've tried: Changing the Target->Settings Mode to Normal, Connect Under Rest, and Hot Plug. None of them make any difference. Target->Program, or ''Program and Verify'' No difference Exiting the ST Link Utility completely, disconnecting physically, and restarting. No difference. Here's what I did to to prove it is not controlling the SPI. I unplug the USB cable to remove power from the Discovery board. I cut power to the attached PCB that has the PGA 112 so it is reset to a gain of 0. I then power that back up, plug in the USB, reconnect the target from the ST Link Utility, and run it. The attached board does not receive any commands form the Discovery board while using the ST link utility!  It is perfectly fine when using the exact same code, but running from the IAR debugger though. This is too weird...has anyone got a suggestion as to what is going on? I cannot imagine for the life of me what the problem is. What has SPI control got to do with whether it's running from the ST Link, or a debugger controlling the ST Link utility??   #discovery #st-link #spi-control

[Tesla DeLorean]

Posted on December 20, 2014 at 03:49

Debuggers tend to enable clocks and peripherals to suit their needs, check (or output) the APB/AHB clock enable registers, make sure you're enabling the SPI on the right APB.

[Rogers.Gary]

Posted on December 20, 2014 at 04:13

Clive1,

I am not changing code at all. It runs fine in the IAR debugger through ST Link - selected in project options. ST Link Utility uses the same driver, except a different interface. How could it possibly rearrange clocks and/or interfaces when I use the same HEX file? Why...or better yet how does the ST Link affect the APB or clocks when this is all in the HEX code file? Please explain...

[Tesla DeLorean]

Posted on December 20, 2014 at 04:38

Debuggers do their own thing to facilitate their operation, a) assume they are invasive, b) what code IAR load/executes in RAM to configure the system may differ from what ST does in their utility.

Unless I misread your description, the .HEX doesn't function absent a debugger either, so assume the problem is with your code, and stop worrying about the debugger. I'd focus on your SPI initialization code, the clocks for the SPI and GPIO bank of the pins it uses.

[Rogers.Gary]

Posted on December 20, 2014 at 04:58

Clive1,

In *both* IAR and the ST Link Utility, the ADC configures and runs OK, the Timers are OK, code execution is OK, printf statements are OK. It's just the SPI that does not work only in ST Link. My initialization and setup code came directly from ST examples for the SPI. It executes 100% fine in IAR. I had little problem getting it to work on the PGA112. What could be the issue with any of my code that allows SPI to run perfectly on IAR, but not on ST Utility? What should I look for? Thanks

[Rogers.Gary]

Posted on December 20, 2014 at 05:17 I've attached the SPI.c file. Can someone please tell me why it would not work correctly only in the ST Link utility, but perfectly fine in the IAR debugger? For completeness, I pasted in at the top the lines from SPI.h file Thanks, Gary ________________ Attachments : SPI.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzrV&d=%2Fa%2F0X0000000bQT%2F_eNMG2hw2C0yicvEhUcmdfhMFVh2vK8QZYbDK7pQ2Zw&asPdf=false

[Tesla DeLorean]

Posted on December 20, 2014 at 05:43

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE); // << PERHAPS YOU NEED THIS

Like I said, the ''debugger'' not the JTAG/SWD transport, download code and execute it on your platform before they hand it too you, that code will likely be more or less complete depending on who wrote it, and what their goals and competence are.

[Rogers.Gary]

Posted on December 20, 2014 at 07:41

clive1,

OK, I now see that the clock isn't enabled for PORTB where the SPI is defined. And thank you for pointed that out, clearly something that was very obvious and I missed it. But it is still not clear how the IAR debugger can ''figure out'' that it's not enabled when not done so explicitly in the code, and then enable it so that it works in that interface. Can you clue me in? Thanks for your help.

[Tesla DeLorean]

Posted on December 20, 2014 at 08:34

IAR downloads it's OWN code onto your platform BEFORE it hands it to YOU. This code likely does a number of things, including enabling clocks it needs to get the system in a state which IT can debug, and process any debugger scripts poking and prodding peripherals into desired states. There isn't any ''magic'' access the debugger is afforded to get to peripherals and APB/AHB buses, it gets access via code it downloads and runs, NOT YOUR CODE. It doesn't care what your code does or needs, it enables what it needs. It doesn't try to fix your code, that's just a convenient side effect in this case.

Like I said initially, the debugger is invasive, and provides you with an artificial run time environment. This environment permits flawed code to run because it changed the initial conditions. The SWO pin is on GPIO bank B, perhaps it is ensuring that pin is suitably configured for SWV functionality.

[Rogers.Gary]

Posted on December 21, 2014 at 05:31

clive1,

Adding the enable for GPIO B clock did the trick. It now works the same with both interfaces. It's a learning process. I'll now take a closer look at the code when something like this happens, as your explanation has helped. Thank you for your advice, time and patience with my questions.