Hex code check.
- Dominant language
- C
- Stars
- 2.8k
- Forks
- 1.1k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 1
Description
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.
Contributor guide
Research direction
Start by reproducing the LPC1788 flashing behavior with the lpc11u35_c027 project base, comparing DAPLink V254 MSD flashing of the HEX file with CMSIS-DAP and J-Link. Investigate whether the MSD path verifies written data and define done as identifying the cause of any corruption or documenting evidence that the issue lies elsewhere.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100