Can not read memory! Disable Read Out Protection and retry

[Rajesh Tripathi]

Posted on April 16, 2017 at 04:55

Hello, I have problem with a custom stm32f437 based board. It was working for few days then suddenly stopped working and can't program it anymore From keil/St-Link setup.

Installed the ST-Link utility (V4.0) and updated firmware on ST-Link. When I try to connect it says

'Can not read memory!

Disable Read Out Protection and retry.'

Not sure how it got into 'Read Out Protection Level 1'  as I had never even used ST-Link Utility.

When I try to switch to ROP level 0 and deselect all sector and apply, it complains

'Could not set Option bytes!

Please reset the target and retry.'

Already reset/retry many time with no improvement!

The board is unusable now. Please help.

#stm32-stlink #stm32f4-read-out-protection #stm32f437

[Tesla DeLorean]

Posted on April 17, 2017 at 13:44

Try reprogramming with BOOT0 pulled high.

[Tesla DeLorean]

Posted on April 17, 2017 at 15:06

>>

I have problem with a custom stm32f437 based board.

Assume no one here is at all familiar with the design of the board, or the software changes that resulted in the failure here.

Review the code for interference with the JTAG/SWD pins.

Review the design for debug connectivity, and ability to use System Loader to access USART1/USART3 or USB

[Rajesh Tripathi]

Posted on June 03, 2017 at 23:39

Programming with BOOT0 pulled high didn't help.

The JTAG/SWD pins are not reused as GPIO so there is no code related to that. There is only 10 lines of extra code to what was generated by STM32CubeMX. Just to poll one GPIO line and toggle 3 other GPIO lines. There is no other code and that's why it's puzzling as to why the board goes into this read only mode.

Can't connect with the System Loader either, always times out. The same system loader setup work fine with STM32F429 discovery board.

Is there a way to recover the board using any other JTAG?SWD tool?

So far 3 boards have gone into this Read only mode own it's own.

[Tesla DeLorean]

Posted on June 04, 2017 at 00:03

Segger has STM32 specific tools for their J-Link, there are J-Link loads for the ST-LINK.

There sounds to be some design issue with your board and firmware, unfortunately I lack psychic skills to debug this remotely.

[Rajesh Tripathi]

Posted on June 04, 2017 at 23:38

Hi Clive one. Thanks a lot for your always prompt response.

I'll try with Segger's JLinkSTM32.exe tool.

What hardware design issue could cause the boards gong to Protection level 1? I'm rather new to STM32 but this seems to be very simple chip with single power supply rail at 3.3V and only few control line like BOOT0/1, NRST etc in comparison to QorIQ P2040/iMX6Q etc I've worked on earlier.

The firmware right now is just few GPIO lines code as this is a co-processor to manage main power on/off with push button.. No other peripherals like USART/I2C/SPI are being used or interrupts enabled. No RTOS either. Just STM32CubeMX generated code for GPIOs compiled with Keil tools.

The Flash loader also doesn't work. I've checked with Scope that BOOT0 is high , BOOT1 is low. And USART3_RX pin is receiving serial pulses but nothing comes out at USART3_TX pin. Atmel's ATSAMA5D35 Micro I worked on earlier has similar serial loader and that always worked.

I'm just trying to understand as what can cause this strange behavior. Generally ST-Link/Serial loader tool is needed to put STM32 in protection level 1. Has anyone else seen the same problems with STM32s and what was cause?

[Tesla DeLorean]

Posted on June 04, 2017 at 23:47

Yes it is a simple enough chip to wire up, not had a problem here designing several functional boards where the system loader works just fine.

The System Loader uses specific pins. The analogue supplies and VCAP pins tend to catch the most people out, driving NRST with a push-pull driver is anoher classic failure mode. Playing 'guess what I've done wrong' is not something I'm interested in doing, sorry..  Your description are far too non-specific for me to understand or replicate. Got a schematic? lets start with that..

[Rajesh Tripathi]

Posted on June 05, 2017 at 00:35

Your prompt response is amazing

🙂

Not sure I can share schematic as It's part of bigger design. VCAP pins just have 2.2uF caps each. VREF+ is tied to VDD with ferrite bead and decoupling caps of 10 and 0.1 uF between them. NRST is just connected to pin 15(RESET♯) of 20 pin JTAG connector. No other device with push pull driving it.

As far as I understand, system loader uses these pins for using USART3

- BOOT0, BOOT1 for mode. BOOT0 should be high and BOOT1 should be low

- NRST. This is active low reset and BOOT0 and BOOT1 are sampled on 4th clock after reset.

-  USART3_RX (PB11 pin 70 ) and USART3_TX(PB10 pin 69) of 144 pin LQFP

Any other pin needed for system loader ?

What else should be checked on VCAP pins? I'm seeing 1.218V on both VCAP pins

Thanks again for your time and your valuable inputs.

[Tesla DeLorean]

Posted on June 05, 2017 at 17:20

The boot loader expects even parity, sending the 0x7F byte at 9600 8E1 is recommended to check responsiveness.

You need to make sure you don't have signalling on PA10 or PC11 as this will be taken as a connection attempt. The USB and CAN pins etc are also being monitored. The design must be reviewed in the sense of how is this different from a board that works.

The option bytes and flash can be changed by code running in the chip.

[Denise Andreozzi]

Posted on June 06, 2017 at 18:34

My team is having a very similar problem with the STM32F407 chip.  Electrically, the circuit is sound.  Have you discovered the root cause of the issue?  If so, please post your results.  We are continuing to debug, but I will post with any new information.