Memory-Loader error

[shravan]

Posted on April 12, 2017 at 15:22

Hi all,

        I am facing some issues here on flash erasing and programming. I am not getting where is the actual problem. I am using STM32F429ZET on our custom board. For testing purpose is used provided blinky example's hex file which support same controller. Problem here is that when i am trying to program this hex file using ST-Link utility it throws errors as:

18:22:34 : ST-LINK SN : 49FF70065178505057391687

18:22:34 : ST-LINK Firmware version : V2J28S618:22:34 : Connected via SWD.18:22:34 : SWD Frequency = 4,0 MHz.18:22:34 : Connection mode : Normal.18:22:34 : Debug in Low Power mode enabled.18:22:34 : Device ID:0x419 18:22:34 : Device flash Size : 512KBytes18:22:34 : Device family :STM32F42xxx/F43xxx18:23:04 : [Blinky.hex] opened successfully.18:23:04 : [Blinky.hex] checksum : 0x000F72B6 18:23:07 : Memory-Loader error18:23:07 : Error occured during erase operation!18:23:07 : Programmed memory Checksum: 0x00000000

Any idea?

Any suggestions might help me.

[shravan]

Posted on April 13, 2017 at 12:28

Hi Clive,

               On first attempt i tried your suggested option with programming algorithm as STM32F4xx but it threw error as Flash TImeout. Reset the Target and try again. That's why i preferred another option as Use External Tool for Flash Programming.  

[shravan]

Posted on April 13, 2017 at 12:39

Hi Max,

            I will let you know about those suggested possible check's result.

 Were you able to program this device on this board before or is it the first time?

      Those boards was not programmed before, its a first attempt.

Do you have several boards or only one? if you have several, you may want to try on another one.

I have two boards.  I tried on both, but unfortunately both boards giving same problem.

[shravan]

Posted on April 13, 2017 at 12:40

Hi Imen,

            I am trying to program from 0x08000000 address.

[Max]

Posted on April 13, 2017 at 13:56

Maybe there is something wrong with this board. 

The STLink is able to get the deviceID, so the SWD connection succeed.

Check the points mentioned earlier and let us know!

[Tesla DeLorean]

Posted on April 13, 2017 at 15:12

Doesn't that suggest that something more fundamentally is wrong with your design? You should look more critically about what is happening.

I'd start by looking at the voltage and capacitors on the VCAP pins. And the supply pins, and power supply stability.

If this is the first board from new manufacture, check a couple of additional boards. If all boards fail, revisit the circuit and netlist with a more critical eye.

Try the GUI version of the most current ST-LINK Utilities.

>>I think this custom board don't have such provision. 

Who designs boards like this? Going to make it very hard for you to cross check things and look for signs of life.

[Alex R]

Posted on April 13, 2017 at 17:43

Hi,

Do you have an external watchdog circuit on your board that can be triggering the CPU reset ?

If yes, do you have a way to disable it?

Alex R.

[Tesla DeLorean]

Posted on April 13, 2017 at 18:44

I think we are definitely into board implementation details, but no specifics have been shared.

Time to drag the board designer into the bring-up party, and probe things like the NRST signal.

[shravan]

Posted on May 03, 2017 at 12:39

Hello again,

As per the suggestions I updated the firmware of ST-Link and it started to flash/erase my custom board but I have a weird behavior of a simple blinky code not working, when I checked with the code I found that control is lost in this following line. 

/* Configure the system clock */

SystemClock_Config(); 

My PPL configurations are as follows and I have used 25MHz crystal 

/*Initializes the CPU, AHB and APB busses clocks*/

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLM = 25; RCC_OscInitStruct.PLL.PLLN = 360; RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; RCC_OscInitStruct.PLL.PLLQ = 7;

[Max]

Posted on May 08, 2017 at 09:08

This sounds like an oscillator issue...

Does the crystal start oscillating? 

Try enabling the MCO pin and look at the clock with a scope.

[shravan]

Posted on May 15, 2017 at 09:03

Hi Max,

Thanks for your reply. I have tested the crystal with the scope and its giving out the frequencies properly. But still my control fails to come out of the 

SystemClock_Config() function. When I debug I found out that its exactly hanging at HAL_Enable_PLL() function which is used to enable main PLL. This is the same case for all of the tested sample codes. But when tested the same code with my STM32 Discovery(stm32f429zit6) all the examples are wotking properly.