Support for STM32L100

[RoganDawes]

I am trying to attach to the STM32L100 on a Wink Hub v1. swdp_scan and jtag_scan both show the device, but neither will allow me to attach to it. It would be great to be able to erase this chip and upload my own firmware to it.

[dragonmux]

Thank you for reporting this. We'll try and address this as part of feature/mass-erase-progress-indication as part of the issue is that the mass erase code in stm32l0.c is commented out

[UweBonnes]

Is reset connected? Can you try to connect under reset? Does the device use longer sleeps. Perhaps setting DBGMCU_CR to allow debug in sleep modes is needed here too lik e.g. implemneted for the STM32F4.

[dragonmux]

Please see the Discord conversation about this. The user is working with a chip they know has been locked.

[RoganDawes]

I'm not 100% confident it has been locked. This is a commercial product, so it would be "correct" if it was locked, but obviously there are no guarantees. As far as I recall, I did try to connect under reset, but I will hook it up again and verify. Will probably only be on the weekend, however.

[dragonmux]

Ah, fair - that doesn't change that the other half of this issue is the lack of mass erase support for STM32L0/L1 which needs fixing anyway

[RoganDawes]

With regards to sleeping, the device is driving a CC1101 radio, to receive transmissions from IoT devices. It is also mains powered (via 12V brick), which suggests that power saving/sleeping is not a priority, vs receiving every transmission.

[UweBonnes]

Can you run BMDA , connect in gdb to :2000, run the commands shown above and report the output on the starting console?

[RoganDawes]

The swdp_scan and jtag_scan commands? Or did you have something else in mind?

[UweBonnes]

I meant the failing attach command. The SWD case would be enough for a start.

[dragonmux]

Rogan, reading through the reference manual - that we are able to see the part via JTAG/SWD even though we can't attach means the part is at most in Level 1 memory protection (this is good news).

Unfortunately, if the part is in L1 protection, this explains why attach fails and we'll need to go about thing differently for parts where this is the case - we can check for this condition by reading STM32Lx_NVM_PECR though and comparing against the value 0xAA - if we compare != then it's L1 and we'll need to provide an attach routine that brings the device back out of protection (mass erase included); if we compare == then we're in business and a normal cortexm_attach() can proceed.

Mass erase in the latter case is implemented by issuing a mass erase operation to the device.

We're working on patches now that will help determine which state your device is in and allow at least its unlock and use.

[UweBonnes]

You can attach to STM32L1 in L1 protection: (gdb) mon s Target voltage: 2.98V Available Targets: No. Att Driver 1 STM32L1x M3 (gdb) att 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x200003ec in ?? () (gdb) mon op show 0x1ff80000: 0x0000 0x0000 ERR

There must be something else going on.

[dragonmux]

@RoganDawes, could you please try the attached PR and report back what the chip scans as? This will shed some light on what's going on and what further steps should be taken.

As it stands, we're planning to take the protection mode switching code and stuff it into stm32lx_protected_mass_erase, and set that up as the mass erase function for that mode so that one can recover devices. We're then going to work on implementing sending an actual mass erase command for the non-protected mass erase implementation. This will solve a long outstanding issue of lack of mass erase implementation for these targets.

[RoganDawes]

Sorry for the delay, I can confirm that this works with the 1.9 release.