Hey,
I started development with Standard SDK on BW16 module. Earlier I was playing with B&T firmware and it’s AT commands but that wasn’t enough for me. I compiled Standard SDK and tried uploading it on my RTL8720DN. I followed this guide [Resources] BW16 Troubleshooting Guide to make sure B&T firmware was erased. Then I compiled Standard SDK according to AN0400 Ameba-D Application Note.
I can successfully upload compiled binaries to my module using ameba image tool (entering UART download mode before that), but then after connecting to rtl via UART terminal it only prints “#” on startup and echoes back everything I send to him. Seems like uploaded firmware is not booting and the module stays in some bootloader code. What might be the reason?
did you use the flash erase function to erase the B&T firmware?
you might want to try activating some example code, and see if that prints out anything. it is possible that the uploaded image is just not doing anything.
Yes, I erased flash via image tool prior to uploading Standard SDK example. It worked as there is no B&T logo printing out. I compiled Standard SDK with UART ATcmd example (inc_hp/platform_opts.h define CONFIG_EXAMPLE_UART_ATCMD 1) but the module does not respond to my commands and does not print any messages via UART. I followed guide in application note to do that so I assume everything was done correctly
@wyy
Simple solution, yet it worked! I used master branch version of Standard SDK, release version works without any problems.
I have another question, don’t know if I should start new topic but I’ll ask here.
I use RTL8720DN as a slave controlled by other uC through AT commands. I want it to provide connection to Azure IoT Hub using TLS 1.2, there is also a custom certificate needed. Can you suggest some examples to start with? I tried to implement an open source mqtt stack on my uC that used TCP socket on RTL controlled via AT commands, but I couldn’t establish secure connection.
I was stuck at the same point @kilimanjaro was stuck.
I am following AN400 - but don’t want to use hardware debugging.
I used git clone GitHub - ambiot/ambd_sdk: Release SDK for AmebaD
to pull down the SDK to my Linux VM
Having used chmod -R 777 ambd_sdk (rather brutal!) to fix the lack of -x permissions on the various .sh and .py files, I did a compile without any changes - it compiled perfectly.
I then used imagetool to push the three files to an rtlduino board using an FTDI adaptor.
The upload appeared to go fine - but I notice that system.bin is not ticked - should it be? What does it do?
I get just the #symbol on startup on the Log_ port. I can get some kind of monitor to run (similar to the one on the BW16 default firmware), but I don’t see the ‘calibration ok’ message.
I notice that the KM0 boot file is just 236 bytes long, whereas screenshots suggest it should be about 4k.
Now I’m not as fluent with git as I need to be, but eventually I worked out that the download gives you the ‘master’ branch even when the dropdown at top left of the link kindly provided by wyv is set to ‘release’.
Tinkering around with git commands, I managed to ‘git checkout -f release’ (had to use the -f flag to blow away the broken ‘master’ branch), re-did the chmod -R command, compiled everything again. uploaded, and now I see sensible things on the Log port for an ‘empty’ application.
And when I enable the AT commands, I see the string AT_UART_CONF: 38400 etc - but nothing on the second UART - so I guess I now need to start checking out the pinmux settings!.
system.bin corresponds to the system data region of flash. As seen in Chapter 9.1.2 and 29.3.3 of the application note, it is used for activating BLE debug capability on certain pins. It is fine to leave it empty.
There is a “default” AT command interface on the LOG_UART pins, which do not need to be specifically enabled. You can control WiFi, BLE, TCP from it.
Some examples may enable a different AT command interface on other UART pins. This may use a set of AT commands that are different from the first.
re system.bin - thanks for the explanation, and sorry I missed that in the AN.
Re default AT command interface, I wasn’t seeing an AT COMMAND READY prompt, but I was seeing the 38400 baud rate message, yet the Log UART still seemed to be running at 115,200.
Anyway, whilst my end project doesn’t need to use AT commands, I thought if I can get that going, it helps me in to the SDK and prove I can actually build a working project.
Just as an experiment, I have modifed component\common\example\uart_atcmd\example_uart_atcmd.h as follows: #elif (CONFIG_AMEBA == AMEBAD )
//#define UART_TX PA_18
//#define UART_RX PA_19
//#define UART_RTS PA_16
//#define UART_CTS PA_17 #define UART_TX PB_1 #define UART_RX PB_2 #define UART_RTS NC #define UART_CTS NC
and I now get the AT COMMAND READY prompt on the second UART.
The LOG_UART pins are default configured to 115200 unless reconfigured in code. I believe the 38400 message is indicating the baud rate for the other UART port, since it also serves as a default output for debug messages in addition to accepting AT commands
I believe there is no specific AT COMMAND READY message on the LOG_UART port. Normally I just hit enter once for the # prompt to show up, then use ATW0 / ATW1 to connect to wifi.
its booting off OTA2 image. Do a “flash write 08106000 0” to corrupt the OTA2 image. Then OTA1 should boot. wrote a serial script to “flash write 08106000 0” then a “reboot uartburn” and then call the Linux tool “tools/linux/image_tool/amebad_image_tool /dev/ttyUSBx” to upload km0_km4_image.bin for “production”.
