olliw42 / mLRS-docu

Documentation for the mLRS project
GNU General Public License v3.0
30 stars 10 forks source link

Trouble with R9 MX #111

Closed Hwurzburg closed 3 months ago

Hwurzburg commented 9 months ago

@olliw42 have been trying to a system setup...flashed R9M TX module with ELRS bootloader and then mLRS,no problem.....flashed via TX the R9MX with ELRS bootloader, no problem....but cant seem to talk via uart port to my ftdi connector using the UARTupload.py script....it runs, the RX is flashing as if in bootloader, but script tries 10 ten times and gives up...

-have tried reversing tx/rx (although its pretty easy to get that right) -have tried no delay to many different delays on powering rx after script starts -have checked connectivity of wires from RX uart pads to duponts

any other suggestions? might have to shelve this and move on...was hoping to post a AP blog post on it once I got it and the wifi link from R9M module running

jlpoltrack commented 9 months ago

@Hwurzburg - welcome

What USB<>UART hardware are you using? I had no success on R9MX using cheap (knockoff?) CP2102 - had to use a FTDI board with the UARTupload.py script.

If you need some help troubleshooting the Discord may be a better place: https://discord.com/invite/vwjzCD6ws5

olliw42 commented 9 months ago

@Hwurzburg

let me ping @brad112358, he is our R9 and ELRS bootloader/flashing expert (I myself only use STLink flashing :))

I'd like to also invite you to the discord channel, it's the better place for the topic

any other suggestions?

probably not an option, but maybe going STLink might be a possibility. The R9MX provides relatively convennient access to the SWD pins.

brad112358 commented 9 months ago

It is important to start the script before powering up the receiver. Plug in the USB to serial TTL adapter first. Then start python the script. Don't connect the receiver to the 5 volt power until after you see "attempting to reboot into bootloader" message. It shouldn't take more than one or two tries.

brad112358 commented 9 months ago

If you can't get it flashed via the bootloader and the serial adapter, the cheap STLink adapters and the STM32cubeprogrammer software should also work as long as you keep the wires relatively short (less than 10cm works for me). https://www.amazon.com/HiLetgo-Emulator-Downloader-Programmer-STM32F103C8T6/dp/B07SQV6VLZ

Hwurzburg commented 9 months ago

I will try to find another FTDI adapter and retry....soldering to less than 0.1 spaced pads is a bit too much for my shaky hands...thanks if you have a recommended FTDI on amazon or elsewhere post the link...thanks again

Hwurzburg commented 9 months ago

It is important to start the script before powering up the receiver. Plug in the USB to serial TTL adapter first. Then start python the script. Don't connect the receiver to the 5 volt power until after you see "attempting to reboot into bootloader" message. It shouldn't take more than one or two tries.

yep tried lots of time with different timing...no joy

jlpoltrack commented 9 months ago

I had success with a board that looks like this: https://www.amazon.com/HiLetgo-FT232RL-Converter-Adapter-Breakout/dp/B00IJXZQ7C/ref=sr_1_1?crid=1SLJKT79N6NPE&keywords=FTDI&qid=1702410540&sprefix=ftdi%2Caps%2C137&sr=8-1

brad112358 commented 9 months ago

The R9MX is much easier to solder than the tiny pads on the R9MM which I only use the bootloader method for. But even for the R9MX, I don't solder the SWD pins. Instead, I build a programming cable useing micro-hook test clips on the thru holes. It's still a little tight, but it's easy to get a reliable temporary connection this way. https://www.amazon.com/gp/product/B078ZC8HSB/

brad112358 commented 9 months ago

It's a few extra steps setting ardupilot parameters correctly, but you can also use serial passthrough with an ardupilot flight controller. You may want to update the receiver this way once you install it in a drone anyway.

olliw42 commented 9 months ago

@Hwurzburg do you have a R9MM or R9MX? I wonder if you might have the wiring wrong, it's different in subtle ways for the two. A wild guess, I know.

Hwurzburg commented 9 months ago

R9MX.....and am using a simular usb-serial adapter as the one inked above...will recheck solder joints on uart io one more time...if the elrs bootloader is flashed,did that put a version of elrs also? If so I might try using it as elrs first

olliw42 commented 9 months ago

the serial wires are when in the "middle" of the four pins, not at one of the end as for the R9MM

I somehow have the feeling that it is something so simple that one doesn't note

Hwurzburg commented 9 months ago

nope....got all that right...

brad112358 commented 9 months ago

Installing the bootloader via OpenTx or EdgeTx does not install ELRS. I wonder if something went wrong with the bootloader install.

olliw42 commented 9 months ago

I wonder if something went wrong with the bootloader install.

that's a good idea

olliw42 commented 9 months ago

is there some way to check the bootloader works, like a specific led behavior?

brad112358 commented 9 months ago

Good point!

First, lets review some background. Specifically, the high level steps after power on when the Elrs bootloader has been flashed via OTx using the FrSky bootloader. The FrSky bootloader resides at the start of flash. The ExpressLRS bootloader resides at the start of flash + 0x4000. After it's flashed, mLRS will reside at the start of flash + 0x8000. At power on, the FrSky bootloader starts and if it doesn't receive a command to load and flash firmware, it starts the firmware at offset 0x4000 which in our case should be the ExpressLRS bootloader. The ExpressLRS bootloader similarly briefly pauses to check for instructions via the serial port, then checks a couple of things and starts the code at offset 0x8000 which will be the mLRS code.

I don't know what the LED behavior is for the FrSky bootloader, but it will be so brief it might be hard to identify anyway.

However, we do have a way to force the ExperssLRS bootloader to keep running and not try to finish the boot process. If the ExpressLRS bootloader sees the button down when it starts, it will continue to monitor the serial port and according to the ExpressLRS documentation, the green and red LEDs blink alternately. I've confirmed this on one of my boards. I observe the red and green LEDs are on for about half a second each, alternating. Note that this is also a way to eliminate any timing issues with the python script.

@Hwurzburg, what LED behavior do you observe if you power on the R9MX with the button held down?

olliw42 commented 9 months ago

fantastic I guess we may want to consider adding a note in point 6 in the docs of how to test the working of the elrs boorloader :)

brad112358 commented 8 months ago

@Hwurzburg, Did you get it flashed and working OK?

Hwurzburg commented 8 months ago

sorry, no...I had many other ArduPilot projects and wiki work on my to-do list so I shelved mLRS for a while...I do hope to revisit it in the new year...especially after 4.5 betas, hopefully in month....

ArtimisFowl888 commented 8 months ago

Hello,

I am having a similar issue with an R9MM and with an R9 mini. I was unable to get to the bootloader using the power method, so I forced it by holding the bind button.

Once I got past that, I got this error message.

Detected the following serial ports on this system: COM14 COM3

=================== FIRMWARE UPLOAD ===================

Bin file 'rx-R9MM-f103rb-elrs-bl-v1.1.00-v1.1.elrs'

Port COM14 @ 420000

Using CRSF (full duplex)!

We were already in bootloader

uploading 44580 bytes...

ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x18' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x18' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x18' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x18' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x15' for block 1 ERROR:xmodem.XMODEM:send error: NAK received 11 times, aborting. [FAILED] Upload failed!

Process finished with exit code -1

Thank you in advance.

olliw42 commented 8 months ago

@brad112358 if you happen to find time, could you look at @ArtimisFowl888 's problem?

brad112358 commented 8 months ago

Good timing, I just yesterday received a R9MM which I haven't flashed yet so I have a fresh one to test with. @ArtimisFowl888, what LED behavior do you observe when you power on the R9MM with the button held down?

ArtimisFowl888 commented 8 months ago

Good timing, I just yesterday received a R9MM which I haven't flashed yet so I have a fresh one to test with. @ArtimisFowl888, what LED behavior do you observe when you power on the R9MM with the button held down?

The red and green led are alternating.

brad112358 commented 8 months ago

Are you seeing the same NAK received message on both the R9MM and the R9 mini? I received a defective R9MX once which had a couple of missing resistors which I suspect would have caused this error (I flashed it via ST-Link, so in my case I didn't notice the serial port was only working in one direction until after I was trying to get it to communicate with the Flight Controller.)

But, if you see the same messages from the python script with two different receivers, it's not likely to be a hardware problem on the receiver.

ArtimisFowl888 commented 8 months ago

I get the message for both receivers.

I have ordered an STlink and an R9MX moth should arrive on Thursday. I will let you know if I get the same message with the MX.

olliw42 commented 8 months ago

many thx guys for working on this! it would be great if the flashing would just become failure proof, the R9 system seems to be among the more popular hardwares for mLRS

ArtimisFowl888 commented 8 months ago

Are you seeing the same NAK received message on both the R9MM and the R9 mini? I received a defective R9MX once which had a couple of missing resistors which I suspect would have caused this error (I flashed it via ST-Link, so in my case I didn't notice the serial port was only working in one direction until after I was trying to get it to communicate with the Flight Controller.)

But, if you see the same messages from the python script with two different receivers, it's not likely to be a hardware problem on the receiver.

My R9MM was previously flashed with ELRS. I re-flashed the bootloader before attempting to flash MLRS.

The R9 mini is new.

brad112358 commented 8 months ago

My R9MM was previously flashed with ELRS. I re-flashed the bootloader before attempting to flash MLRS.

This is useful information as there is almost no difference between flashing ELRS and flashing mLRS on the R9 system. Note that if you already had the bootloader flashed for ELRS, you didn't need to reflash it, but it also shouldn't hurt.

Just to be sure, I tested with my new R9MM what happens when the wrong .frk file is flashed via OpenTx and the only case where powering on with the button pressed for about 5 seconds resulted in the expected alternating red and green LEDs was when the correct r9mm_elrs_bl.frk firmware is flashed. This seems to confirm that the bootloader is not your problem.

When you previously flashed ELRS, did you install the bootloader and then use ExpressLRS Configurator with the same exact PC and serial adapter (or FC) as you are trying now? I ask because the ELRS Configurator runs the UARTupload.py script to do the flash so there shouldn't be much difference between what you did to flash ELRS and what you are attempting now.

Did you use passthrough with a Betaflight FC when you flashed ELRS or did you use a USB serial adapter? If you are not using the same hardware, you might try it with the same FC or serial adapter you used for ELRS. It might also be useful if you can confirm that you can still flash ELRS to the R9MM then we can focus on what is different for mLRS.

If you have already connected the R9MM to a Ardupilot FC, it is also possible, though a bit tedious, to manually configure serial passthrough in Ardupilot and flash this way instead of using a USB serial adapter.

I normally only run Linux on all of my computers, but I you seem to be running Windows so I've dug out a Windows test setup. When it finishes installing it's many updates, I'll test the python script with the new R9MM there, though I know it has worked in the past.

brad112358 commented 8 months ago

OK. I did get mLRS installed on my new R9MM using Windows 10 and a USB tty serial adapter. When I wrote this section of the mLRS R9 documentation, I left out the Windows specific details because I've only really used and developed software for Unix and Linux for the past 40 years. I assumed getting Git and Python installed on Windows would be trivial and perhaps it is supposed to be, but I found getting the required python modules installed to be painful. If my experience is typical, we need more details in the documentation and it probably needs to be written by a windows user, not by me. It also seems that the ELRS python code does not support python 3.12 so I had to install 3.11.

But none of that seems like the problem for the two users who have reported trouble here. They both seemed to have already gotten past the problems I had getting python and the required pyserial module installed properly.

@ArtimisFowl888 please provide some details on what is connected at COM14 and what is different from when you flashed ELRS. I can't seem to reproduce any problem. It all just works for me. At this point, the only thing I can guess might be wrong is wiring or a problem with the specific USB adapter. Perhaps a photo? If we can't identify a wiring issue, I guess I can try a few other serial adapters I have around here.

olliw42 commented 8 months ago

I think the interesting question is why it worked to flash ELRS but appears to not work for flashing mLRS

i.e., I think your suggestion that @ArtimisFowl888 should try and see if he still can flash ELRS was a good one. If he can flash ELRS but not mLRS using the eaxt very same environment, i.e., PC, adapter, wiring, etc., it should narrow down the error source

ArtimisFowl888 commented 8 months ago

I have been using a USB serial adapter to flash mLRS. I wired the R9MM to the betaflight fc that I used to flash ELRS and was able to succesfully flash ELRS. When I attempted to flash mLRS I was able to get to 99% before i got the same error as before.

Searching flight controllers

FC found from 'COM5'

Detected the following serial ports on this system: COM5

=================== FIRMWARE UPLOAD ===================

Bin file 'rx-R9MM-f103rb-v1.0.hex'

Port COM5 @ 420000

Using CRSF (full duplex)!

======== PASSTHROUGH INIT ======== Trying to initialize COM5 @ 420000 Warning: 'No CLI available. Already in passthrough mode?, If this fails reboot FC and try again!'

Attempting to reboot into bootloader...

[1] retry...

Bootloader version found : 'v0.5.4'

Bootloader type found : 'R9MM'

Got into bootloader after: 1 attempts

Wait sync... sync OK

uploading 92976 bytes...

1% 3% 4% 6% 7% 8% 10% 11% 12% 14% 15% ... 88% 89% 91% 92% 94% 95% 96% 98% 99% ERROR:xmodem.XMODEM:send error: expected ACK; got b'\x86' ERROR:xmodem.XMODEM:send error: expected ACK; got b'\n' ERROR:xmodem.XMODEM:send error: expected ACK; got b'\r' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' ERROR:xmodem.XMODEM:send error: expected ACK; got b'=' [FAILED] Upload failed!

Process finished with exit code -1

brad112358 commented 8 months ago

Please try again with the rx-R9MM-f103rb-elrs-bl-v1.1.00-v1.1.elrs file like you did with the USB adapter. Not the .hex file.

ArtimisFowl888 commented 8 months ago

Awesome. That worked upload was successful.

I might be missing something, and this is probably for a different thread, but when I look at the Lua script, I get a param upload error, and I cannot edit the TX and RX parameters.

I am using a TX16s with an R9M module running mLRS 1.1.00.

olliw42 commented 8 months ago

Awesome. That worked upload was successful.

fantastic

can you identify the reason for why it wasn't working in the first place? If it's possible to avoid whatever happened by means of improved docs we should want to do that.

the lua param upload error usually means the radio and tx module are not talking to each other. You need to set the external module to CRSF protocol (it's a OpenTx/EdgeTx radio, right?): https://github.com/olliw42/mLRS-docu/blob/master/docs/CRSF.md (the tx module should be configured for ctsf per initial flash, there should be no need to invoke the CLI)

ArtimisFowl888 commented 8 months ago

I think the issue is with the USB TTL adapter I am using. https://www.amazon.com/dp/B00LODGRV8?psc=1&ref=ppx_yo2ov_dt_b_product_details When I switched the spare betaflight board that I use to flash ELRS and used the correct .elrs firmware it just worked.

I have verified that I have my model external rf set to CSRF and 400k. I still have the same param error.

screen-2024-01-04-134154 screen-2024-01-04-134007

jlpoltrack commented 8 months ago

@ArtimisFowl888 Are you able to edit the settings when only the Tx is plugged in? If so, I wonder if previously flashing to ELRS is the cause of this.

ArtimisFowl888 commented 8 months ago

The LUA script does not load when just the TX is powered.

I did have ELRS previously flashed to the TX. I saw a post on the discord that the R9M might need a chip erase.

brad112358 commented 8 months ago

@olliw42, I guess this is a case where, for diagnostic purposes, it would be nice to have an easy way to clear mLRS tx/rx settings without having to use the CLI or LUA or build a custom firmware. But, I can't see how having ELRS previously installed could cause any problem.

@ArtimisFowl888, regarding your serial adapter, if you haven't already, please test it to see if the receiver side might be damaged. You can do this by using a terminal emulator (when I have to use windows, I use PuTTY). Disconnect the serial side of the USB adapter and plug it in to a USB port. Start the terminal emulator and select the com port corresponding to the USB tty serial adapter and set the baud rate to 420000. Be sure local echo is turned off. Then start the terminal emulator session and type a few characters. You should not seem them appear on the screen. Then connect the Rx pin to the Tx pin on the USB adapter, A jumper shorting block is handy for this. Type some more characters and this time you should see them on the screen. If you don't, the serial adapter is probably damaged or defective.

brad112358 commented 8 months ago

@ArtimisFowl888, What does the LED on the Tx module do when the radio is powered on?

jlpoltrack commented 8 months ago

@brad112358 Could certainly be wrong but am thinking that as mLRS uses the upper part of flash for storing parameters and this area may not get erased as part of the ELRS flashing causing the issue.

olliw42 commented 8 months ago

there is some sort of checks before the flash area used for the params is accepted as valid. We could increase the checks, but it's not like it is super likely already now that it would take wrong setup values. Not impossible however.

he probably will have to invoke the cli

brad112358 commented 8 months ago

Using the CLI will be a pain if he doesn't have a working USB ttl serial adapter. Using a FC via passthrough is possible with Ardupilot, but it's a strange thing to do for the Tx CLI. The other option if he doesn't have the ability to build mLRS from source is to provide him with a temporary firmware file which clears the parameters.

jlpoltrack commented 8 months ago

Don't forget that R9M UART is inverted so normal USB<>UART won't suffice. Something like ESP32 could be used as a bridge.

brad112358 commented 8 months ago

@jlpoltrack, Good point. Perhaps the temporary firmware binary approach is the easiest.

olliw42 commented 8 months ago

mLRS has the option of baked in parameters since long, just needs this to be uncommented: https://github.com/olliw42/mLRS/blob/main/mLRS/Common/common_conf.h#L39

brad112358 commented 8 months ago

Yes, building a temporary firmware with that line uncommented is what I was suggesting.

ArtimisFowl888 commented 8 months ago

@brad112358, the serial adapter did not work.

The green LED on the RX and TX are both blinking.

I have an eps32, but I do not have an inverter I have parts ordered to make an inverter that will arrive next week.

olliw42 commented 8 months ago

@ArtimisFowl888 pl unzip and then flash this firmware tx-R9M-f103c8-elrs-bl-v1.1.03-@4ee9029-force.zip it forces the setup to CRSF, so the lua script should then work (if this was the problem) you can't store param changes however, so you need to flash back the "old" firmware

ArtimisFowl888 commented 8 months ago

I flashed the new firmware, but the Lua scripts no longer displays correctly. This happened on the previous firmware but it would eventually load or it would work after rebooting the radio.

screen-2024-01-05-150123

I am able to get rc signal to the autopilot. I can see outputs in mission planner.