search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

REALTEK_RTL8195AM - larger image drops RTL8195AM out of USB #4681

Closed JanneKiiskila closed 7 years ago

JanneKiiskila commented 7 years ago

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

Bug

Target REALTEK_RTL8195A

Toolchain: GCC_ARM

Toolchain version:

mbed-cli version: (mbed --version) 1.1.1

meed-os sha: (git log -n1 --oneline)

Using fork from Archady, see linked issue 4665

DAPLink version: ?

Expected behavior

Flashing a mbed-os-example-client with client logs enabled should just enable more logs.

Actual behavior

Flashing fails, the whole Realtek Ameba boards gets dropped out of USB and device disappears.

Steps to reproduce

compile mbed-os-example; modify mbed_app.json to enable client logs https://github.com/ARMmbed/mbed-os-example-client/blob/master/mbed_app.json#L36

mbed compile -m REALTEK_RTL8195AM
cp BUILD/REALTEK_RTL8195AM/GCC_ARM/mbed-os-example-client.bin /media/jankii01/MBED && sync

To recover you must reconnect the USB cable completely.

JanneKiiskila commented 7 years ago

@Archcady @adbridge @marcuschangarm @0xc0170

JanneKiiskila commented 7 years ago

When trying to re-flash with the non-debug image - it still fails. This is a hard problem for me now.

target_flash_erase_sector() : 0x6d000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x6e000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x6f000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x70000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x71000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x72000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x73000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x74000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x75000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x76000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x77000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x78000
set event : MSC_TIMEOUT_SPLIT_FILES_EVENT 
msc_event_timeout 
main : usb disconnected

I can't even flash in the smaller image now, so is the board bricked? After USB disconnection and re-connection;

main : usb disconnected 
TIMEOUT !!! 
main : usb disconnected 

~
Please Re-boogain, or re-burn the flash image

1st reflash, trying to put in the mbed-os-example-wifi now.

jankii01@ubuntu:~/mbed/mbed-os-example-wifi$ cp ./BUILD/REALTEK_RTL8195AM/GCC_ARM/mbed-os-example-wifi.bin /media/jankii01/MBED && sync
cp: cannot create regular file '/media/jankii01/MBED': Permission denied

Is the DAPLINK SW on this old? USB cable out again and re-try... Copy works, but it doesn't still work, from my point of view. The minicom terminal is just saying Cannot open /dev/ttyACM0!. It should have resetted and started printing out whatever the wifi example wants to print.

JanneKiiskila commented 7 years ago

Flashing in the mbed-os-example-wifi gets this one done;

CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x4c000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x4d000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x4e000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x4f000
CPU clock : *(0x14) = 0x21 
target_flash_erase_sector() : 0x50000
set event : MSC_TIMEOUT_SPLIT_FILES_EVENT 
msc_event_timeout 
main : usb disconnected

So, there are less sectors to flash, but still it fails to start the app.

...

Several retries later... mbed-os-example-wifi started working once I pressed the Pdn button on the opposite side of the SMA-connector. However, when putting back in the mbed-os-example-client (even w/o logs), it fails again.

=========================================================

ROM Version: 0.3

Build ToolChain Version: gcc version 4.8.3 (Realtek ASDK-4.8.3p1 Build 2003) 

=========================================================
Check boot type form eFuse
SPI Initial
Image1 length: 0x0, Image Addr: 0x0
Image1 Validation Incorrect !!!
Please Re-boot and try again, or re-burn the flash image

mbed-os-example-client is using the PR from Archady, but the mbed-os-example-wifi was using mbed-os with hash commit c9e63f14085f5751ff5ead79a7c0382d50a813a2 (HEAD -> mbed-os-5.5, tag: mbed_lib_rev145, tag: mbed-os-5.5.1, tag: latest, origin/mbed-os-5.5)

JanneKiiskila commented 7 years ago

Yep, it requires 2 flashes back/forth these two mbed-os versions, is the boot address now somehow changing between these two?

0xc0170 commented 7 years ago

cc @Archcady

Archcady commented 7 years ago

The Image1 Validation Incorrect !!! message seems like a corrupted image, I'm trying to reproduce this at my side

JanneKiiskila commented 7 years ago

The image is created simply by compiling the mbed-os-example-client so that the debug prints are turned on.

git clone https://github.com/ARMmbed/mbed-os-example-client.git git checkout easy-rtl-wifi

mbed deploy cp configs/wifi_realtek_v4.json mbed_app.json edit mbed_app.json -> put in your WiFi ssid + passphrase AND modify the mbed_app.json to enable the tracing ("mbed-trace.enable": 0 -> "mbed-trace.enable": 1)

mbed compile -m REALTEK_RTL8195AM

JanneKiiskila commented 7 years ago

I updated the DAPLINK SW to it and now I can actually get the trace image also to the device. Client handshake however still fails.

But, the remedy for this particular problems seems to be to update the DAPLINK. Kudos for @marcuschangarm for pointing that out to me.

https://developer.mbed.org/platforms/REALTEK-RTL8195AM/

The instructions are a bit confusing in this part.

To update DAP firmware, please follow the steps:

  1. Press and hold the button next to CON2.
  2. Press the button next to CON1.
  3. Release the button you press and hold in step 1.

Instruction 3. should be just "Release the button next to CON2 while keeping button next to CON1 held down." I had a bit of trouble understanding that part.

Anyways, one does NOT simply copy over the file -> I get an out of space error. I had to manually DELETE the firmware.bin 1st and after that copy the newer one (renamed to be firmware.bin) to the special drive.

So, I think this issue can be closed with some changes to the documentation stressing the importance of updating the DAPLINK before trying to seriously use that board.

After the update the board does not appear as MBED anymore, but as a DAPLINK under the /media -folder in my virtual Ubuntu.

marcuschangarm commented 7 years ago

@JanneKiiskila

Do you also get a 

RTL8195A[Driver]: no beacon for a long time, disconnect or roaming

after some time?

JanneKiiskila commented 7 years ago

Yes, I'm seeing that occasionally as well (TCP).

JanneKiiskila commented 7 years ago

Even with the updated DAPLINK SW I'm seeing sometimes the "USB device malfunctioned" error notifications in Windows, so there's definitely something still going on with the firmware. Is the very latest DAPLINK used?

Archcady commented 7 years ago

cc @tung7970

tung7970 commented 7 years ago

@JanneKiiskila Regarding the daplink firmware, that should be the latest one, but it's not using the latest daplink codebase. Will work with RTL8195AM team to get the firmware up to date.

TCP is another issue tho.