I have a RTL8195AM dev board, and followed the instructions in the URL today:
https://www.amebaiot.com/en/change-dap-firmware/
Replace the firmware file inside the drive “CRP DISABLD”.
I unmount the device peacefully and remount it.
The device keeping pop up “CRP DISABLD”, never return to DAP mbed mode.
Don’t know what happened.
I need more information about how to fix it.
Thanks!
when it appears as CRP_DISABLD, is there a firmware.bin file in the drive?
I suggest trying to update the firmware again by deleting the firmware.bin file then copying the firmware into the drive.
Yes, the CRP_DISABLD drive always contains firmware.bin file. Even I changed the file into DAP_FW_Ameba_V12_1_3-2M.bin, when I replug the cable, the file back to the original filename firmware.bin.
Hi @walkerfleck
Is it possible that the button next to usb CON2 is damaged? If the button is stuck in a pressed state, it would cause the chip to enter CRP_DISABLD mode every time USB is connected.
Here are two files that I have tried and verified working, download the files and remove the .xml extension before using them.
DAP_FW_MBED_RTL8195AM_V1.bin.xml (60 KB)
DAP_FW_Ameba_V12_1_3-2M.bin.xml (32.3 KB)
Hi @wyy
I’ve check the button J24 next to CON2 and there is no problem on it.
I’ve tried files you provided. No matter what file I put in, the CRP_DISABLD drive always back to firmware.bin (65.5k) after I re-plug it.
Hi @walkerfleck
Can you provide more info on how you checked button J24?
There is a method to verify that the firmware is updating correctly:
After copying in the firmware and reconnecting, copy the firmware.bin file out, and do a binary comparison with the original file copied in. The binary data should match.
If you updated with DAP_FW_MBED_RTL8195AM_V1.bin, the binary data of firmware.bin should be the same as the original file.
If you updated with DAP_FW_Ameba_V12_1_3-2M.bin, the initial 32KB binary data of firmware.bin should be the same as the original file, with extra space filled in with 0xFF.
Hi @wyy
I check the voltage from two ends of the button J24 when the board is on.
It is high on normal state, when I push the button, it turns low.
And the firmware seems not copied by this way. I check the binary content of firmware.bin, the first 1k data always be 0xFF.
I am not sure which step was wrong on copying the firmware file. Let me show my procedures on changing the firmware, you can check them for me:
renaming the file to firmware.bin is not necessary. I have never done it, but I am not sure if it has any detrimental effects.
instead of unmounting and disconnecting the drive, you can also choose to leave it connected, and press the button next to USB CON1 to reset the DAP chip.
Hi @wyy
I’ve tried the reset button, but still not work.
I think it’s time to try jtag connector to program the board.
Thank you anyway!
Hi ,
After I tried different ways , finally I discovered that the only way can successfully upgrade firmware is under windows 10 environment, the Linux can not work at all.
I’ve compared the firmware.bin with the source, they are the same ( a lot of 0xFF padding at the end as expected )
I found there is a new behavior of new version DAP_FW_Ameba_V12_1_3-2M, that is the orange and red led flash sequentially and constantly.
I just need to know what this kind of behavior indicates? Is it normal?
that is good to hear. This is the first time I am aware that firmware upgrade fails on Linux. I suspect it may be a driver issue.
The flashing LEDs are normal. You can choose to disable the flashing LEDs by using the LED_Disable version of the firmware.
I don’t know why this fails under Linux but this worked to me:
For linux users - if ‘drag and drop’ seems to fail to ugprade firmware, try:
umount /media/[USER]/CRP\ DISABLD
sudo dd if=[BINARY] of=/dev/[DEVICE DRIVE] seek=4