crc error on firmware #45
Comments
|
Hi, Are you able to flash the same UF2 file using the .EXE version of ltchiptool? (the GUI) Also, a list of package versions present in your environment could help: |
|
"C:\Users\DIeMONd.platformio\penv.libretiny\Scripts\python.exe" -V "C:\Users\DIeMONd.platformio\penv.libretiny\Scripts\python.exe" -m pip list bitstruct 8.19.0 C:\Users\DIeMONd.platformio\penv.libretiny\Scripts\python.exe" -m ltchiptool -V gui |
|
Can you enable verbose logging in ltchiptool GUI and post the full flashing log? |
|
I: Found new device: COM1 - Последовательный порт |
|
The log you posted shows a different error ( |
|
I have similar problem, log output: |
|
It seems like ltchiptool is trying to write out of bounds of the flash ( |
|
Technically, all of its write are out of bounds by 0x200000 and wrap around as a work-around for protected areas, so 0x329F0A becomes 0x129F0A It seems all bk7231t uf2 files have this issue, including the kickstart bin; https://github.com/libretiny-eu/esphome-kickstart/releases/download/v23.12.15/kickstart-bk7231t-2023-12-15.uf2 |
|
It would be helpful to read the flash back to determine whether something was actually written at 0x329F0A and the error is in the CRC command or if the write itself also failed. |
|
I'll try to do so as time allows, will be sometime today. Feel free to join the discord channel for discussion as well; https://discord.com/channels/967863521511608370/1146821147644657734 When this happens, we do know that the write of the app partition offset is actually successful, and the device does reboot to it. There is a different BK7231T issue with bin files though (or at least used to be, but I don't remember how to verify/reproduce that at the moment). |
|
The device indeed responds with a CRC value of 0xFFFFFFFF (or 0 if inversed). The logs are really helpful in this case. Looking at the disassembly for BK7231S_1.0.5, there seems to be a problem with unaligned access to the flash. In particular, it reads chunks of 256 bytes into RAM, then calculates the CRC. It can't read properly if the addresses are not aligned. crc_start = v1[1] | (v1[2] << 8) | (v1[3] << 16) | (v1[4] << 24);
crc_end = v1[5] | (v1[6] << 8) | (v1[7] << 16) | (v1[8] << 24);
crc_init_table();
v6 = 0;
v7 = crc_end - crc_start + 1;
while ( v6 < v7 >> 8 )
{
flash_read(&bufa, crc_start, 256);
crc_value = crc_calc(crc_value, &bufa, 0x100u);
crc_start += 256;
v6 = (v6 + 1) & 0xFFFEFFFF;
}
flash_protect_maybe(1);
*v16 = crc_value;
v16[2] = BYTE2(crc_value);
v16[3] = HIBYTE(crc_value);
cmd = uart_write_response(16, 8, v16);Fixing this will require a change in bk7231tools, which also accounts for the unaligned data writing when checking the CRC. |
|
Here is the before and after. Before is a Tuya devboard stock firmware. I wrote the same https://github.com/libretiny-eu/esphome-kickstart/releases/download/v23.12.15/kickstart-bk7231t-2023-12-15.uf2 kickstart uf2 file. Full backup of device before uf2 write: wb3s-pre-uf2.zip |
hi, can you help with the error in the platformio project. On other generic-bk7231n-qfn32-tuya boards, the firmware works well. there is a problem with reading the crc, openbeken is flashing normally and working, so the board and programmer are working.
Cut Platformio.ini
The text was updated successfully, but these errors were encountered: