STM32 DISCOVERY DISC-1 LOSES PROGRAM AFTER POWER OFF?

[DNguy.18]

Dear all!!

I have a STM32 DISCOVERY DISC-1 and I have a problem. I created .hex file by KeilC and I programed this board by STM32 ST-LINK Utility and everthing seem be OK.

But, when I turned off power and after that I turned on, board was not run. I connected board with STM32 ST-LINK Utility and checked the program, device memory was disappear.

I don't know why what happen with my board. Anyone can help me????

Thank you very much!!!!

[Tesla DeLorean]

Is this a DELL machine?

Make sure you have current firmware on the ST-LINK, and that you don't have any AV software or performance/diagnostic software writing to the mbed mass-storage drive.

[DNguy.18]

Yes. I'm using DELL machine at my company to program my board. But I also use my HP laptop to program and get same problem.

Firmware of ST-LINK is OK. And because STM32F407VGT6 chip on my board was not working, I replaced by STM32F407VET6. So I didn't know that job was a cause of my problem

[Tesla DeLorean]

It is not my experience that parts magically erase.

Just saying a write to the mbed MSC might precipitate an erase. Current ST-LINK firmware is V2J32

[DNguy.18]

yes. current ST-LINK firmware is V2J32M. And when I connect my board, driver connect such as image below. I don't know there is any software writing to Mbed MSC as you say

[S.Ma]

okay, interesting case.

First, open your HEX file. Each text line is a contiguous block of bytes to program in the micro.

==> Confirm the addresses are located in the STM32 flash area. Can't be too sure.

==> Murphy's law tells to check the interrupt and reset vectors location.

Second, does your code contains functions changing the content of the flash? (or emulated EEPROM in flash?)

Third, after erase and programming, leave the programming tool, restart it, and read the internal memory of the mciro. Make sure the STM32 target is the right once (or memory mapping may mismatch). Save as HEX file.

Fourth, power off - on your device and repease the third step. and compare both files.

Fifth: Have you used any memory protection function in your device?

I would guess something shows up before reaching the end of this list.

[DNguy.18]

okay, thanks for your reply!!!

I will try these step. I hope it work for me. I will show you some results after I try it.

[DNguy.18]

I think I have found my problem. Because the original chip on STM32-F4 DISCOVERY is STM32F407VGT6, it is damaged and I replace by STM32F407VET6 with less memory than F407VGT6. When I created .hex file, I didn't change MCU type in KeilC. So I think this is the reason of my problem.

[S.Ma]

Memory mismatch is indeed a cause of malfunction. When you select a target MCU in the IDE, it selects a linker configuration file which defines the memory areas, addresses and sizes. The last chance to get a linker warning when the codesize gets too big. Rebuild with the proper target and check for linker warnings or errors. For more details, linker generates a MAP file (option) to look a consumed memory and estimation of the used stack size. Of course, when using function pointers, the MAP file data is an understatement...

[Tesla DeLorean]

Potentially, in this case both have the same die, with the same 1MB Flash Array.

I would probably try to see if the problem occurs with some fresh boards, and try to isolate this as a board/rework specific issue, or a more systemic issue impacting all boards, and then find the commonality there vs the thousands of successful applications of the same technology.