STM32F030CCT6 ST-Link problem

Thomas Jespersen · ‎2015-09-15

Posted on September 16, 2015 at 00:04

Hi.

I have just upgraded one of our boards from using the STM32F030C8T6 to the more or less pin-compatible STM32F030CCT6.

The only change that had to be made was to supply the one extra power supply rail to pin 35 and 36.

Though when scanning the JTAG chain with the ST-Link software it doesn't detect the right chip. This is the output log:

00:01:03 : ST-LINK SN : 53FF71065078485750200387

00:01:03 : ST-LINK Firmware version : V2J23S0

00:01:03 : Connected via SWD.

00:01:03 : SWD Frequency = 480 KHz.

00:01:03 : Connection mode : Normal.

00:01:03 : Device ID:0x442

00:01:03 : Device flash Size : 256KBytes

00:01:03 : Device family :STM32F091xB-xC/F098xC

Furthermore we can't get our firmware to work on this device, which seems to go constantly into hardfault.

Any recommendations are appreciated.

Best regards

Thomas Jespersen

#stm32f030 #st-link #stm32f030cct6

Tesla DeLorean · ‎2015-09-15

Posted on September 16, 2015 at 01:20

Do they behave better if you treat them like the F09 devices the scan-chain suggests they are? This is with most current ST-LINK Utilities, right?

What are the full markings on the parts?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Thomas Jespersen · ‎2015-09-16

Posted on September 16, 2015 at 17:25

Hi Clive.

I haven't tried treating it as an STM32F091, why should that be necessary? And how are you thinking of treating it as it were a F09 device - within the debugging/programming environment? Because if so, the whole project and low level libraries would have to be changed.

The complete identifier on the chip is:

STM32F

030CCT6

GH24H 93

CHN 523

Regards Thomas

Tesla DeLorean · ‎2015-09-16

Posted on September 16, 2015 at 18:02

I don't work for ST, I was suggesting it as a course of action as a means to confirm it's electrical connectivity requirements, and software functionality, matched the die as reported by the software.

If the software doesn't work now, and the one for the reported die is different, it would seem to suggest it's a mismarked device. The markings might permit the staff at ST to do an audit of the production/testing data, and tell you if it's their fault, or comes from some other third-party.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Thomas Jespersen · ‎2015-09-16

Posted on September 16, 2015 at 23:01

I have now digged more into the datasheets and can see that both the STM32F030CC device and the STM32F091 family has the same device ID: 0x442.

So I guess this is why the software is confused.

I have now forced some more programming of the proper device and got some decent results.

Until I now started trying to migrate our previous project to this new chip.

We are using FreeRTOS in this system, where we needed quite some heap/stack for the tasks, which is the main reason for upgrading the chip.

I am able to run a simple LED blinking task, but when I start the main task where math (sqrt, sin, cos) etc. is being used it always seem to go into ''Infinite Loop'' somehow.

I can't seem to tell though how it happens in here, but I suspect that it has something to do with writing to a wrong memory address?

But why should this problem yet again all of a sudden appear on this ''big-brother'' device?

Regards Thomas