REALTEK_RTL8195AM - larger image drops RTL8195AM out of USB

[JanneKiiskila]

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

Description

• Type: Bug
• Related issue: Enable sdram usage of REALTEK_RTL8195AM #4665
• Priority: Blocker

---

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]

@Archcady @adbridge @marcuschangarm @0xc0170

[JanneKiiskila]

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]

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)

• are they now somehow incompatible?

[JanneKiiskila]

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

[0xc0170]

cc @Archcady

[Archcady]

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

[JanneKiiskila]

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

• to pull in Update easy-connect / Realtek WiFi mbed-os-example-client#268

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]

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]

@JanneKiiskila

Do you also get a

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

after some time?

[JanneKiiskila]

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

[JanneKiiskila]

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]

cc @tung7970