Problem with partially erased default firmware on BW16

[boatbodger]

I am working to build a product using the BW16 and have designed a custom PCB.
I have read the helpful post at [Resources] BW16 Troubleshooting Guide
After various difficulties, I managed to ‘clean’ a BW16 using the OTA method and that unit is now happily working with the Arduino boot loader.

For the second unit I was working on, I noticed that the default firmware has a command:
flash erase chip
And I thought I would try that. It worked. Even though an error message was reported in the middle of the errors, the phrase “Erase successful!” was emitted, and I found I could then enter the bootloader which starts by emitting 0x15 characters.

Now, for my third I used the ‘flash erase chip’ command again - and it appeared to work. However, if I use the “enter boot loader” sequence (EN low, LogTx low, EN high, Log Tx high) the module outputs:
Flash Downloader Started
instead of the series of 0x15 characters.
Neither the Realtek Image Tool nor the Arduino flash uploaders recognise this output.

If I start the unit normally (i.e. EN low, EN high), it outputs a # symbol (like the default firmware), and echoes commands typed, but the commands don’t do anything. If I hold down a key to make a very long command, I eventually see a message coming back saying <> - so there is something running there.

Not surprisingly, the second UART does not operate so I can no longer use AT commands.

Now during the prototyping, there was a brief moment when the module was exposed to 5V on its power pins - not 3.3, so I assumed I’d damaged the module in some subtle way, and replaced it with a fresh one.

However this fresh one ALSO has gone to the same state after using the ‘flash erase chip’ command in the standard firmware - it seems that this ‘bricks’ the device.

With that said, is there some different uploading tool (from the suppliers of the original firmware) which speaks the protocol which is expected from the “Flash Downloader Started” output? It would be nice to get these two modules back if I can.

[wyy]

@boatbodger

The flash update mode of the RTL872xD series of chips is activated by holding LogTX low while toggling EN. The normal output of entering flash update mode is the message #Flash Download Start from the LogUART output, followed by repeated NAK (0x15) as it waits for the ImageTool program to establish communications.

From your descriptions, the erased chips outputting nothing but the initial # symbol seems to match what I have seen of a chip with no code running from flash. Which seems to indicate that for both chips, the flash erase chip command worked as expected.

It seems to me that your main issue is getting an image uploaded. I would try to use a logic analyzer and verify if the chip is sending out 0x15 on the LogTX line after entering update mode, as that is the first step in communicating with the image upload tool. Perhaps try out different USB-UART adaptors as well.

[boatbodger]

I can confirm that my logic analyser shows that there are no NAKs being emitted. That is exactly the problem.
(I had not previously noticed before that the string “Flash Download Start” is sent before the NAKs, as I’d never had to examine the startup that closely before).

I had thought that the downloader was running from ROM (and therefore not erasible), so I am now very puzzled as to what state these chips can be in…

[boatbodger]

Update - If I manually operate the lines in that order, I am now seeing NAKs on the logic analyser. It seems to be some timeing thing with the auto-upload tool. I will do more work and update. The auto update tool seems to behave differently. It pulls EN low, then pulls LogTx low, then releases both simultaneously. I will try and modify this behaviour to do as you suggest - first pull down LogTx, then toggle EN, then release logTx.
I will report back my findings. Thank you for confirmation that I probably haven’t broken the modules!

[wyy]

the code to enter download mode that sends the #Flash Download Start and NAKs do indeed live in ROM and are not erasable. After establishing communication with the image tool, a flash loader image is first transmitted and run from RAM, which is then responsible for receiving the main program image and writing that into flash.

I have personally swapped out the flash chip on my BW16 with a larger capacity blank one, and the image upload process still works normally, so your issue seems to be rather strange.

[boatbodger]

My situation is that I’m using a PIC1545 to act as the USB/Serial bridge, and the autoflash from GitHub - jojoling/ameba_bw16_autoflash.
I have emulated the DTR/RTS logic (done by two transistors if using a standard serial bridge) in my PIC code.
This works perfectly on my first prototype board, and on an rtlduino board.
However, on my second prototype it does not.
I think this is either to do with timing issues, OR possibly because the PIC output is not able to pull the LogTx line down when it is still under control of the firmware in the BW16.

I had assumed that the LogTx line was only sampled as EN goes from low to high, and that actually, it was ‘kinder’ to the BW16 (if not the PIC!) if the pic did not pull it hard low prior to EN being pulled low.
Also, the logic shown in the Jojoling’s autoflash.cpp is different:
void reset_method(FD fd , int method) {

// DTR RTS EN BUN
//   1  1   1  1
//   0  0   1  1
//   1  0   0  1
//   0  1   1  0

if(method) {

    //set_DTR_RTS(fd,0x3);
    //sleep_ms(2000);

    // enter uart flash download mode.
    set_DTR_RTS(fd,0x2); // EN LOW
    sleep_ms(500);
    set_DTR_RTS(fd,0x1); // TX_LOG LOW
    sleep_ms(200);
    set_DTR_RTS(fd,0x3); // normal
    sleep_ms(500);

} else {
    // reset system.
    set_DTR_RTS(fd,0x2); // EN LOW
    sleep_ms(500);
    set_DTR_RTS(fd,0x3); // normal
    //sleep_ms(500);
}

}
You can see that his algorithm also assumes that LogTx is only sampled as EN rises, in that he first brings EN low, then pulls LogTx low, then releases both simultaneously (OK, there will be implementation differences in terms of exactly now “simultaneous” that is - see below!)

I experimented with the algorithm you suggested (i.e. LogTx low, then en low, then en high then logtx released) and found it to make no difference (other than causing a fight between the BW16 and the PIC).

I then increased the delay between releasing EN and releasing Tx. Bizzarely, even though without that increased delay the module sometimes appears to be going into download mode, it is not sending out the NAKs. With this increased delay it behaves correctly.

I suspect my PIC implementation of the logic is faster than the combination of the CS340 and transistors, and perhaps the LogTx is sampled twice during start up - and the ROM code was detecting the low pull in the first sample, then testing it again and finding it was high.

For others on this journey, I’m using about 16ms delay betwen releasing EN and releasing LogTx.
8ms is not enough.

I have attached two screenshots The first shows successful operation with the ‘slug’ in place. Yellow line is EN, blue line is LogTx

Although resolution is poor at this timebase, you can see the “fuzz” of the Flash Loader started message followed by about fifteen NAKs. Although they look distorted here, they look fine if the 'scope timebase is at an appropriate speed to resolve 112,500 bit/s.

The second screen shot shows what happens without adding this delay. However, as I say, this seems to vary with sample of the BW16 moduld. Some don’t seem to need it:

The four bursts of activity on the LogTx line - when examined are as follows (in hex)
0d 23 i.e. “#”
and then (in ascii) “calibration ok” - in other words the app is running (this is after I’ve done a successful upload).

So with all said and done, this turns out to be a ‘feature’ of the autoloader when used with a serial bridge which is “too fast” when manipulating the data control lines, and where some samples of the BW16 seem to take longer to sample the LogTx line than others.

Thanks - as ever - for your responses.

[wyy]

Thanks for posting your experiments and scope captures.

The autoflasher reset process using DTR & RTS is a community effort based on a similar circuit found on some ESP32 boards. It is definitely not tested as extensively as the regular image tool, so it is good to see more data on the timing requirements.