cancel
Showing results for 
Search instead for 
Did you mean: 

SMT32G030 and Unique Device ID is missing.

K_Szynalski
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

7 REPLIES 7
Uwe Bonnes
Principal III

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
Lead II

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
Associate III

@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.

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.

Uwe Bonnes
Principal III

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.

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

K_Szynalski
Associate III

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.