T3S3 (SX1280) support #13
Comments
|
Run |
|
How does that work with custom firmware built from the repo (this T3S3 is the 2.4 GHz version)? I thought that was just the auto installer, or am I missing something? |
|
I've just looked a little bit into this and it seems the RNODE_NG_22 target is being used for the T3S3 at the moment, which is for the SX1262. There is no target for the SX1280, which is the modem your board uses. I will reopen this issue as a reminder for me to add support (it should be fairly simple). Would you be willing to do pilot testing on your board? |
|
Yeah, fine by me, 100% willing to help with testing or any integration! I had actually tried to do some of the support, but I seemed to have hit a roadblock for that last step: Here is the board config if that helps at all. I had trouble with bluetooth compilation enabled so I set it to false just to get past that. I also was trying to get a custom environment, because of this power boost problem which I need to go through the sx1280 library to see if it has that support enabled: From LilyGo's Documentation:
|
|
Okay. The Boards.h layout changed in the last release. I will get back to you on Monday with an updated config for your board and we can take it from there.
…On 6 July 2024 23:03:53 BST, R ***@***.***> wrote:
Yeah, fine by me, 100% willing to help with testing! I had actually tried to do some of the support, but I seemed to have hit a roadblock for that last step:
Here is the board config if that helps at all. I had trouble with bluetooth compilation enabled so I set it to false just to get past that.
```
#elif BOARD_MODEL == BOARD_T3_S3_V1_2_SX1280_PA
#define HAS_BLUETOOTH false
#define HAS_PMU true
#define HAS_EEPROM true
#define EEPROM_SIZE 296 // minimum EEPROM size
#define EEPROM_OFFSET EEPROM_SIZE - EEPROM_RESERVED
#define MODEM SX1280
#define HAS_BUSY true
#define HAS_RF_SWITCH_RX_TX true
const int pin_cs = 7;
const int pin_reset = 8;
const int pin_rxen = 21;
const int pin_txen = 10;
const int pin_dio = 9;
const int pin_busy = 36;
const int pin_tcxo_enable = -1;
const int pin_led_rx = -1;
const int pin_led_tx = 37;
```
--
Reply to this email directly or view it on GitHub:
#13 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
|
|
Alright. Let's get started. @starlight-traveler Can you please confirm this is the correct product page for the device? |
|
Okay, good news! I have just added a corrected board config to the |
|
I have also added the checks for the PA, do not worry. Please set the |
|
Thanks this is great! Will continue to work on this, as I can't tell if this is a hardware problem, but esptool is timing out when flashing to the chip, may need to change the config: Put board into flashing mode by holding BOOT button while momentarily pressing the RESET button. Hit enter when done.
Ran it when esptool.py v4.7.0
Will continue to see what this issue is, maybe one of the configs? This is a brand new, out of the box chip (also that is the correct link! |
|
You are most welcome.
Please make sure nothing else is accessing the serial port, e.g. RNSd or Arduino-IDE.
If you're sure nothing else is trying to access that serial port, try fiddling with the serial baud rate for flashing in rnodeconf.
…On 9 July 2024 11:20:55 BST, R ***@***.***> wrote:
Thanks this is great!
Will continue to work on this, as I can't tell if this is a hardware problem, but esptool is timing out when flashing to the chip, may need to change the config:
Put board into flashing mode by holding BOOT button while momentarily pressing the RESET button. Hit enter when done.
> arduino-cli upload -p /dev/tty.usbmodem2101 --fqbn esp32:esp32:esp32s3
> esptool.py v4.5.1
> Serial port /dev/tty.usbmodem2101
> Connecting...
> Chip is ESP32-S3 (revision v0.1)
> Features: WiFi, BLE
> Crystal is 40MHz
> MAC: 34:b7:da:58:65:a4
> Uploading stub...
> Running stub...
> Stub running...
> Changing baud rate to 921600
> Changed.
> Configuring flash size...
> Flash will be erased from 0x00000000 to 0x00003fff...
> Flash will be erased from 0x00008000 to 0x00008fff...
> Flash will be erased from 0x0000e000 to 0x0000ffff...
> Flash will be erased from 0x00010000 to 0x000f6fff...
> Compressed 15104 bytes to 10430...
> Writing at 0x00000000... (100 %)
> Wrote 15104 bytes (10430 compressed) at 0x00000000 in 0.3 seconds (effective 452.5 kbit/s)...
> Hash of data verified.
> Compressed 3072 bytes to 134...
> Writing at 0x00008000... (100 %)
> Wrote 3072 bytes (134 compressed) at 0x00008000 in 0.1 seconds (effective 390.3 kbit/s)...
> Hash of data verified.
> Compressed 8192 bytes to 47...
> Writing at 0x0000e000... (100 %)
> Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 555.4 kbit/s)...
> Hash of data verified.
> Compressed 942880 bytes to 575580...
> Writing at 0x00010000... (2 %)
> Writing at 0x00019ee5... (5 %)
> Traceback (most recent call last):
> File "esptool/__init__.py", line 1032, in _main
> File "esptool/__init__.py", line 832, in main
> File "esptool/cmds.py", line 586, in write_flash
> File "esptool/loader.py", line 131, in inner
> File "esptool/loader.py", line 1030, in flash_defl_block
> File "esptool/loader.py", line 435, in check_command
> File "esptool/loader.py", line 404, in command
> File "esptool/loader.py", line 337, in read
> StopIteration
>
> A fatal error occurred: The chip stopped responding.
> Failed uploading: uploading error: exit status 2
> make: *** [upload-t3s3] Error 1
Ran it when esptool.py v4.7.0
> esptool.py v4.7.0
> Serial port /dev/tty.usbmodem2101
> Connecting...
> Chip is ESP32-S3 (QFN56) (revision v0.1)
> Features: WiFi, BLE, Embedded Flash 4MB (XMC), Embedded PSRAM 2MB (AP_3v3)
> Crystal is 40MHz
> MAC: 34:b7:da:58:65:a4
> Uploading stub...
> Running stub...
> Stub running...
> Configuring flash size...
> Flash will be erased from 0x00210000 to 0x003effff...
> Compressed 1966080 bytes to 1782227...
> Writing at 0x0025667b... (13 %)Traceback (most recent call last):
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/__init__.py", line 1139, in _main
> main()
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/__init__.py", line 923, in main
> operation_func(esp, args)
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/cmds.py", line 598, in write_flash
> esp.flash_defl_block(block, seq, timeout=timeout)
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/loader.py", line 131, in inner
> return func(*args, **kwargs)
> ^^^^^^^^^^^^^^^^^^^^^
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/loader.py", line 1077, in flash_defl_block
> self.check_command(
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/loader.py", line 467, in check_command
> val, data = self.command(op, data, chk, timeout=timeout)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/loader.py", line 436, in command
> p = self.read()
> ^^^^^^^^^^^
> File "/opt/homebrew/Cellar/esptool/4.7.0_1/libexec/lib/python3.12/site-packages/esptool/loader.py", line 369, in read
> return next(self._slip_reader)
> ^^^^^^^^^^^^^^^^^^^^^^^
> StopIteration
>
> A fatal error occurred: The chip stopped responding.
Will continue to see what this issue is, maybe one of the configs? This is a brand new, out of the box chip (also that is the correct link!
--
Reply to this email directly or view it on GitHub:
#13 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
|
|
Alright! Making progress. Switched to Linux and fixed baud rate and it worked to upload! Though now we are stuck on "Device Starting" and this error:
Will try to investigate, though perhaps you know off the top of your head. |
|
Pins are wrong, I need to review the boards.h. |
|
Oh, it seems that there is a TX and RX switch on the SX1280 for the T3S3, but it's just one pin. Now this will need some extra support added. I will tackle this tomorrow. https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/master/examples/RadioLibExamples/Transmit_Interrupt/utilities.h#L446 |
|
Cool, no problem! Thanks again! |
|
I have not forgotten about this, but I am very busy! I will work more on this soon when I have time, hopefully next week. |
|
Of course haha, no problem! Thanks for working on this in your spare time, take however long you need. If you need any testing or integration stuff done let me know! |
|
Apologies I have not had time to work on this recently. Something to note though, you may wish to ensure that your buffer sizes are similar to the ones I have selected in this commit: I hope to have an implementation for the TX / RX switch soon. |
|
Hey! No rush! Moved on to another facet of my project, should be able to handle the buffer size given it is transmitting flatbufffer/flatbuffer schema. Thanks for the work as always! |
|
I found the switch logic i hope it can help. Im too dummy to implement :) : https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/master/examples/T3S3Factory/T3S3Factory.ino |
|
Why did github not email me when you posted that comment? Strange. Anyway, I've got good news. I'm working on throwing my homebrewed SX1280 driver in the bin and using RadioLib instead, which means all the hard work regarding TX/RX switching will be done for me. Hopefully this will land in a PR soon. |
|
Any new info about the process? i'm Very thankfull! |
|
Please test it and let me know if it works. It's on the dev branch. It may not as of current as I think the TX power error on ESP32 boards is still present, but let me know ;) |
|
I think we have had this discussion before, but how would we provision the firmware hash when we can't use rnodeconf -a to do so as there is no firmware hash step -- never quite understood how to get around this issue (once I do I can start testing off what is in dev): |
|
Hey @starlight-traveler ! Yesterday we worked hard with @jacobeva (He worked on it more than I did 😄 ) and he showed me a lot of things. For hash first run: ./partition_hashes ./build/esp32.esp32.esp32s3/RNode_Firmware_CE.ino.bin And you good to go 😃 Other thing i need to add this command to "work" rnodeconf -r --product 03 --model a5 --hwrev 1 /dev/ttyACM0 without the node said Hardware failure. |
|
Regarding provisioning the RNode, wifihero is most of the way there.
To provision it, please run `rnodeconf -r --product 03 --model ab --hwrev 1 /dev/ttyACM0`
(The reason the model changed is because I realised it conflicted with one already set in rnodeconf for the 433MHz model of the T3S3)
@WifiHero91, if you do recompile your firmware (you don't have to), wipe your EEPROM again and use that command above else it won't boot :)
…On 13 October 2024 08:51:33 BST, WifiHero91 ***@***.***> wrote:
Hey @starlight-traveler ! Yesterday we worked hard with @jacobeva (He worked on it more than I did 😄 ) and he showed me a lot of things.
For hash first run: ./partition_hashes ./build/esp32.esp32.esp32s3/RNode_Firmware_CE.ino.bin
After it generate the hash and copy to rnodeconf /dev/ttyACM0 --firmware-hash de6f2acd09e186acc51a5a62b9f9fd4adc2d293001562d122d1426a564bc0894
And you good to go 😃
Other thing i need to add this command to "work" rnodeconf -r --product 03 --model a5 --hwrev 1 /dev/ttyACM0 without the node said Hardware failure.
--
Reply to this email directly or view it on GitHub:
#13 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
An update. The T3S3 SX1280 with PA now works on the dev branch, but it still has issues sending / receiving split packets at the moment. I am currently investigating the issue. |
|
Okay, I've solved the split packet problem. These boards now work at low speeds, but there is currently an issue causing crashes when sending large files. I suspect it's to do with the queue size. I'm continuing to look at this. |
Wanted to inquire about what does the rnodeconf utility refers to when it means "fail to provision", unsure of where in the manual the documentation for this is, there was a thread here, but following the rough thought process still leads me to fail to provision regardless of the bootstrap EEPROM values:
markqvist/Reticulum#477
For reference I think I have made the necessary changes to support the 2.4 GHz version of the T3S3, but unable to flash it.
Here is the modified Makefile for this board with the custom firmware:
Logs:
The text was updated successfully, but these errors were encountered: