Hex code check.

[fabio-ric-silva]

Hi there, I'm new on here. I hope I'm able to helping people, and receiving it as well.

So, I'm using Daplink project about two years.

I'm using the 254 revision, and I have some problem.

Does the Daplink V254 when used to flash the processor, by MSD, has some kind of data guarantee, verifying what written during the flash process?

It has been recurrent, a strange behavior!

Some LPC1788 processors, when being written using the DAPLINK and HEX file, after some time, just crashes the code and get stuck. If I get the same HEX code and write it up using a Jlink for example, it works fine. If I get the same HEX code and write it up using the DAPLINK through the CMSIS-DAP, it works fine.

It takes me to the sure idea of something getting wrong in the flash/writing process, corrupting some data during that process, and as the DAPLINK doesn't make the written data check, it corrupts the firmware creating those strange behaviors of the processor firmware.

The project that I have used as project base is the lpc11u35_c027. That project was developed for using the LPC1768 processor, but the LPC1788 is the same family.

Thanks in advance!

Sincrely;

Fábio.

[mbrossard]

AFAIK, DAPLink does not verify (and in the case of the LPC1768 the flash support does not support Verify (https://github.com/ARMmbed/DAPLink/blob/main/source/family/nxp/lpc1768/flash_blob.c#L58). You could try using pyOCD: pyocd cmd starts a command-line interface, I use the savemem to dump the flash content.

[fabio-ric-silva]

Yes, I see now! Unhappily, now I'm totally sure that during the writing process, it has some mistaken byte written!

@mbrossard, thank you so much, I will think on some way of using it!

I didn't find much information about PyOcd.

Perhaps, does it is possible to enable the verify flag, or implement it? I have lost dozens of hours looking for some solution, but no way of finding it!

Thank you so much!

Sincerely;

[carlosperate]

I think if automation mode is enabled, then DAPLink will verify each block inmediately after it's written. If the flash algo contains a "verify" function it will use that, but otherwise it will simply read the data back in small chunks with the "standard" swd_read_memory() and do a memcmp:

https://github.com/ARMmbed/DAPLink/blob/1c60ddb5a2b9203c7d44ac089ac5772b9e9e6d31/source/daplink/interface/target_flash.c#L251-L290

To enable automation you can follow these instructions: https://github.com/ARMmbed/DAPLink/blob/main/docs/ENABLE_AUTOMATION.md

[fabio-ric-silva]

Well, first of all, thank you so much @carlosperate, for your time on it!

So, I think that I didn't understand it.

The automation process is used for what, exactly?

It has just it usage, but, it hasn't a consistent explanation!

Could you help me on it?

Thanks in advance!

[fabio-ric-silva]

Hi there, I'm here again!

So, I have been trying to understand the "Flash Algo", and the mechanism behind it, with no success! Does someone already have put it on the code for verifying the written code on the flash?

I have been doing lots of tests and really, depending on the environment, the speed, and the size of the code to be written, it causes miswritten on the flash.. I flash it up using the daplink and using the J-link I read the code and compare them, and there are some miswritten bytes...

Even though I have taken a better interface using buffers and so on, sometimes the error is there!

Of course, it is normal, cause of that when using commercial flash programmers, they have the option for checking during or after data program in the target, as J-flash (j-link software) does!

Could, someone, helping me set a flash code verifying code ?

Thanks in advance!

Sincerely

Fábio, Brazil.

[carlosperate]

With automation enabled I think DAPLink should be verifying each block it writes it, not with the flash algo, but by reading the data back via DAP. I assume you've already enabled automation and DAPLink hasn't thrown an error when flashing a file via the MSD drive?

What kind of programme are you writting to flash? Is it possible the programme is actually writting to flash when it starts running? Can you try to flash a hex file with a known repeating pattern that does nothing?