0

I am trying to make some custom firmware for a MIDI controller (AKAI LPD8). There is an STM32F102R8T6 chip in the unit. I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.

Some information and thing I have tried:

  • The firmware that came with the unit works, so the chip is not broken
  • Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
  • I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
  • The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
  • Tried both the STM32CubeProgrammer and stm32flash, but none connects.

I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.

Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?

Any solution/tips?

pynting
  • 1
  • 1

2 Answers2

0

Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.

If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).

If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.

Tom V
  • 4,827
  • 2
  • 5
  • 22
  • The PCROP protection seemed plausible at first, but upon further reading, that would at least give off a response with device id etc when trying to communicate trough USART for example. And in addition, it seems like that level of protection is not applicable for this lower tear device. I will try to probe around tomorrow and see if I get something with a scope, even though I would have suspected any activity would be captured by the serial input. I tried to send 0x7F to the UART RX, but got no reply either. – pynting Aug 19 '21 at 19:55
0

After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.

A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.

pynting
  • 1
  • 1