STM32L432 NUCLEO: bricked GPIO?

[thermalcity1]

Posted on November 04, 2016 at 23:12

Here's a little background. I run Arch Linux, and have been using the arm-none-eabi suite and openocd since early 2013 to program STM32s, first L1s and F4s, and now L4s. Except for vector.o from the appropriate libopencm3 library, all the code was written by me. I'm simply trying to say that I'm not entirely new to STM32s.

Anyway, as of this morning, I'm the unfortunate possessor of, not just one, but two, STM32L432 NUCLEOs that appear to be defunct. Both have exactly the same problem. And they didn't have it yesterday.Each GPIO port's registers contain the same number: the reset value of the GPIO's mode register. Indeed, all 256 words of the block allocated to each GPIO contains the reset value. For example, GPIOA's block contains 0xabffffff repeated 256 times.And this appears to be a permanent condition. Nothing I tried affected the problem at all. I even installed the windows ST-LINK Utility in a Vista virtual machine, and had a go with it. The result? ''Error occurred during memory writing!'' every time I tried to alter one of the affected registers.As far as I can tell (which isn't very far) the problem appears to affect only the GPIOs. The only other subsystem I use in my ''blink the user LED'' application is the RCC. It seems to work properly. At least I can flip bits in it. (I have code for other subsystems. But if I can't select alternate functions for GPIO pins, those subsystems won't work.)Summing up: my code runs just as I would expect. But since the ports I use right now, GPIO and GPIOB, are inoperable, the code doesn't do a thing that's useful. Both of these devices have been flashed dozens of times while I piece together my code. I can hypothesize that some random glitch in my PC or USB hub might cause a device to fail in this bizarre fashion. But two of them? Within hours of each other? And with the same symptoms?Just to see what might happen, I broke out a brand new L432 NUCLEO, hooked it up to the same USB cable connected to the same USB hub, then used the ST-LINK Utility to copy the code from it. No harm seemed to be done. The third device is still blinking merrily. But I'm not eager to flash it, unless someone can hint as to what bricked the GPIOs in the other two.Any ideas? For extra credit: can they be unbricked?

[Uwe Bonnes]

Posted on November 08, 2016 at 11:59

Let the module run in the debugger. Break into the debugger. Post a register dump of the GPIO Port in question. Using the ST headers something like ''p /x *GPIOA'' would do. With libopencm3, you probably have to query all registers maually. Don't forget the LOCK registers. It seems libopencm3 does  not yet map the lock registers !

[thermalcity1 · Accepted solution]

Posted on November 26, 2016 at 02:28

I should have posted this several days ago. But sometimes life gets in the way.

Two or three weeks ago, I posted the note at the top of this thread, The only response to it wasn't helpful, so I pressed on independently. After several days, I realized that (a) I was the victim of senior citizen brainfade, and (b) the L432 GPIOs were quite all right. The L4X2 RCC register map does not, I repeat NOT, plainly indicate gaps between successive registers like just about every other STM32 register map I've studied over the last few years. So my code blithely made them contiguous, with the result that I was setting and clearing bits in the wrong registers. It's remarkable how much better things work once you discover and correct this problem. Next, my L432's GPIOs weren't bricked. Once I sorted the RCC, I/O started working right. However, it's still true that both arm-none-eabi-gcc and the ST-LINK Utility frequently report that the entire one-kilobyte block allocated to a GPIO is filled with the default MODER value. This is repeatable, for me at least, on F446, L476, and L432 Nucleo boards. Just because I can, I'm uploading a couple of files I used to diagnose the problem. The C file is my entry in the yet-to-be-announced ''Shortest Program That Actually Does Something'' competition. It's accompanied by a truly cheesy linker script. The two files furthered my education. Perhaps they'll do the same for you. ________________ Attachments : Basic.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzbm&d=%2Fa%2F0X0000000bOJ%2FhzUKRzIxTc0y7NIyOpGYI_HOda1.zFogdlux.Se4zYA&asPdf=falseBasic.ld : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzbh&d=%2Fa%2F0X0000000bOI%2FBzUm6AbsXeDavhF0zmD3M8CuY3xKumbOj.1AyP6sZgc&asPdf=false