Tag Archives: documentation

STM32 Unique ID Register on L1 parts

Posted by KarlP on 23 September, 2013 5 comments

Last week I mentioned I was seeing duplicate “Unique” ID registers on some STM32L151 parts [1], and included some memory dumps of the three unique ID registers as proof.

However, I had foolishly assumed that on the L1 the Unique ID register was three contiguous 32 bit registers, as it is on the F0, F1, F2, F3 and F4. (The base address changes, but that’s normal and expected)

On the L1, the registers are actually at offset 0, offset 4, and offset 0x14. Thanks for nothing ST! :(
(Oh, and L1 Medium+ and High Density devices use a different base address too, good job)

Here’s some more complete memory dumps for the same three parts I was looking at last week.

UID31:0 UID63:32 UID95:64
Part A 0x0e473233 0x30343433 0x00290031
Part B 0x0e473233 0x30343433 0x00320032
Part C 0x0e473233 0x30343433 0x00380030

Reading other reference manuals, and seeing that the UID registers often have 8 bits of unsigned “Wafer number”, 7 bytes of ASCII Lot number, and 4 bytes of X/Y wafer coordinates in BCD, I would interpret my part “A” above as

Wafer Number Lot Number X/Y coords
Hex 0x0e 0x47323330343433 0x00290031
Natural 0x0e G230443 X=0029, Y=0031

For reference, here are some full dumps of that section of memory. “0x7b747800” is what I had been looking at as UID bits 95:64, note that there are other bits in this section with fixed values, no idea what they mean :)

Part A

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00290031  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x029f067e  0x035a0000
0x1ff80080: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
0x1ff80090: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
(gdb)

Part B

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00320032  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50685  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

Part C

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00380030  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50689  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

[1] Again, these are STM32L151C6T6 parts, revision V, package markings “GH254 VG” and “CHN309”

Getting started with ARM Cortex-M3 (STM32L1xxx) programming

Posted by KarlP on 23 November, 2011 1 comments

So yeah, we fixed the linux development and programming tools for the STM32 series of ARM cortex M3 chips. And I spent quite a few weeks getting distracted by the tools, and never got around to actually developing for the platform.

Today I sat down to try and wire up a Microchip MRF24J40MA 802.15.4 module to the STM32L discovery board. Seemed straight forward enough, “what pins are for SPI”

“…..” What the… These pins could be anywhere! The reference manual doesn’t say, it refers to the datasheet, which has a table, “Table 5, Alternate function input/output” on page 35 of the actual device datasheet, revision 4. That table says that there are two SPI ports, and they can be made available on a variety of pins. Apparently, SPI1 and SPI2 can be made available on two separate sets of pins each!

All well and good, but how? That’s for another day :)

Adabas D, hibernate and compound primary keys

Posted by KarlP on 11 November, 2008 None comments

lastly, My (least) favourite application here at work, that beauty that uses Adabas D as the database server, also makes liberal use of compound keys. However, in our useage, one portion of that key is always fixed, so when I started trying to replace a lot of the raw jdbc with hibernate as I mentioned earlier, I just put the fixed portion as a regular column, and labelled the varying column with the @Id notation. This worked just fine for reads, and for most of the basic writes we were doing at the time. (Where the write simply changed a field in the table) However, when we tried to update an object property, (By object I mean, myObject.complicatedChild = blah, not just myObject.integerField = wop) it all failed.

Error: ASSIGNMENT IMPOSSIBLE, CHAR VALUE TOO LONG
SQLState:  22001
ErrorCode: -2010

Excellent…..

SAP isn’t very helpful on what that means, it seems to just try and say that, well, you tried to put too big a char value into a char column. Like hell I said, but went off to hibernate debugging to see just what exactly was going on. Which led me to discover that the hibernate code simply wasn’t working!

The generated hibernate code:

update TABLE set
FIXED_PART_OF_KEY=3,
ID_OF_OTHER_OBJECT=4
where REGULAR_PART_OF_KEY ='somekey'

This by itself was failing! but if you take out the FIXED_PART_OF_KEY from the update though, it all works just fine! (This was actually a longer process of elimination, with a lot more rows initially) So, even though there is only one row where the regular part of the key matched “somekey” I went ahead and converted to fully using compound keys across the project, suspecting some inanity from within.

And low and behold, it all started working again. Hooray!  I use the @IdClass method, as it seems to fit our code best.

So:

  1. add @IdClass to original entity
  2. remove @Column attributes from the original ID entity, and put them in the new IdClass
  3. put @Id attributes on both columns in the original entity
  4. add equals and hashcode implementations to the IdClass, and mark as @Embeddable
  5. Add a constructor to the IdClass to deal with the “fixed” portion of the key

Lastly, any other object that was referencing this just by the regular part of the key now needs to be updated as well. so @JoinColumn get’s replaced with @JoinColumns, and the dangling property for the unused fixed portion of the key is deleted.

Moral of the story? Don’t use Adabas D, it’s archaic and has a terribly old jdbc driver. Don’t use Compound Keys if you have a choice. It just causes extra pain.

Versions used: hibernate 3.2.6GA and java 6. JDBC driver for adabas provided by SAG.