Skip to main content
K_Szynalski
K_Szynalski
Associate II
March 7, 2020
Solved

SMT32G030 and Unique Device ID is missing.

  • March 7, 2020
  • 5 replies
  • 3451 views

Is there any plan to provide Unique Device ID registers, together with second calibration point for Temperature Sensor in STM32G030xx?

Initially, I expected these data being missing in stm32g030xx.h and DS by simple mistake. I really miss these 2 features. I tried to find some data in memory, but every access generates Hard Fault and I gave up.

This topic has been closed for replies.
Best answer by Andreas Bolsch

How did you try to read from these addresses? I've used debug access via STLink and openOCD. The device I've used is of 942. Since the package variants (and moreover G031, G030, too) use the same die, I can hardly image that read works on some devices but fails on others. Invalid contents (i.e. not programmed at all) might occur, but I don't think ST bothers with customizing address decoding for the different variants.

5 replies

Uwe Bonnes
Uwe Bonnes
Chief
March 8, 2020

All the features you are missing require test time == money. Not to do those tests allows to offer a cheaper chip. Pay more like for a G031 and you get those features.

Andreas Bolsch
Andreas Bolsch
Lead III
March 8, 2020

Despite the fact not beeing guaranteed in RM/DS, they're there, for an G030J6, Rev. Z:

> mdw 0x1FFF7590 3

0x1fff7590: 005c009d 31365017 20313643

> mdh 0x1FFF75A8

0x1fff75a8: 040d

> mdh 0x1FFF75CA 

0x1fff75ca: 0562

On this particular device the TS_CAL1/2 values yield a quite reasonable temperature. Of course, this might change for a different manufacturing lot ... So, don't rely on this.

Probably these values are programmed upon wafer test before sawing and packaging (anything else would be rather silly, as the UID is based chip location on wafer).

K_Szynalski
K_SzynalskiAuthor
Associate II
March 8, 2020

@Andreas Thanks, but read access to 0x1FFF7590 (and others) generates Hard Fault in STM32G030K6T6, rev. Z, Production date wk1941.

Flash memory size data register and Package data register can be read, the others not.

@Uwe I asked if there is a plan to revise STM32G030 chip to add missing funcionality. I didn't ask you for replacement proposal.

Andreas Bolsch
Andreas BolschBest answer
Lead III
March 8, 2020

How did you try to read from these addresses? I've used debug access via STLink and openOCD. The device I've used is of 942. Since the package variants (and moreover G031, G030, too) use the same die, I can hardly image that read works on some devices but fails on others. Invalid contents (i.e. not programmed at all) might occur, but I don't think ST bothers with customizing address decoding for the different variants.

waclawek.jan
waclawek.jan
Super User
March 8, 2020

The 'G0 has ECC on FLASH. I don't say this is the case, but that could be in theory used for per-location access limitation (subject to FLASH granularity).

JW

Uwe Bonnes
Uwe Bonnes
Chief
March 8, 2020

At least TS_CAL1 is mentioned in the datasheet and so should be readable.96-bit unique ID is however not mentioned. But as there is only one chip id 0x466 for both G030 and G031 it might be available too.

K_Szynalski
K_SzynalskiAuthor
Associate II
March 10, 2020

Thank you all for providing a basic questions. Sometimes I sit to close to the screen to see the obvious errors. :)

Unique ID registers are available at locations starting from 0x1FFF7590. I found the error in my address definitions taken from STM32L031K6... Reading from wrong address caused Hard Fault. Now it works fine and I can read all UID registers and more. Chip ID 0x466, revision Z.

BTW. TS_CAL2 seems to be stored at address 0x1FFF75CA. This value is correct considering TS_CAL30 (stored at 0x1FFF75AA) and sensor voltage slope as a function of temperature.

There are no missing features; all data is available. Case closed.

Terms & ConditionsAccessibility statement