Modules with STM32F103C8 MCUs are not supported in release builds (e.g. URUAV TMX5, VANTAC, etc.)
pascallanger opened this issue · 55 comments
This module is using wrong components with the majors being:
- STM32 with 64KB of flash (STM32F103C8) instead of 128KB (STM32F103CB)
- NAND (C00) instead of XOR (C86) affecting telemetry
If you have purchased this module, you should go back to your reseller and claim your money back since the hardware is not matching the description (64KB vs 128KB).
I can confirm that this also applies to the URUAV TMX5 Lite variant. Same MCU, same flash :(
Can you elaborate how the NAND flash is affecting telemetry? I had some really odd problems with the TMX5 lite and a FrSky D4R-II receiver. Range test was fine but when flying (~10m ) I lost control for about 3 seconds, no "telemetry lost" or "RSSI critical" warning from my radio. Happened multiple times. I am using the current v1.3.1.49 build, the module came with a really old version (1.2.xxx).
NAND flash
Nothing to do with flash, just a logic gate that's supposed to invert the telemetry signal but isn't the correct type.
Never mind, must have been all that LiPo smoke exposure after digging the burning battery out of the ground ;-D
The STM32 on the TMX5 is most likely able to go above the 64KB limit that the manufacturer indicates in the datasheet. While it can store up to 128KB which you are writing with the current Multi tooling, we've seen these modules having erratic behaviors which shows that the flash is not reliable above the 64KB... Just think about it, the components which have a full good flash are sold as128KB the others at 64KB, this is how things work.
Now if you want to fly with it, it's your take but personally I won't take the risk...
It's not worth the risk, too bad I stumbled across this issue after wrecking my copter. However, the TMX5 module has so far been working fine for indoor flying, no problems with flysky and frsky D8/D16. Really awesome experience. It may have been a faulty PPM wire that caused my initial problems. That would explain the failsafe event without "low RSSI/telemetry lost" warning from my radio. Since I got my money back I am going to try to replace the STM32 with the proper STM32F103CBT6.
Vantac Lite modules are also affected by the wrong STM32 chip, added to the subject.
Could you please clarify that to me? I purchased this module https://www.banggood.com/URUAV-TMX5-4-IN-1-A7105-CC2500-CYRF6936-NRF24L01+-Multi-Protocol-Transmitter-Module-Compatible-FrSky-X9D-X10-Transmitter-p-1525898.html?
And it claims to be MCU: STM32F103CBT6(128K ROM, 20K RAM)
Arrived today, and I wanted to upgrade it just to see the NEW NOTE that it's not supported (anymore?).
I opened it up, but to be honest I can't say if this is a 'B' or an '8'. How do I find out?
Thanks
Made this pic. It's hard to make it as large as possible. I really can't say ....
That's a C8. The B has a single straight line down the left hand edge.
Your best option is to return it as it is not what they claim it to be and purchase the iRangeX IRX4 Lite
For comparison, here's a photo of the STM32F103CB in my IRX4 module. Once you know what they look like, the 8 and the B become easier to distinguish.
Thanks for clarification and F*CK. :(
Btw: Would it be ok to swap the chip for one of these? https://www.aliexpress.com/item/4000113089300.html?spm=a2g0o.productlist.0.0.48c62f0d0BZCPo&algo_pvid=4c39b621-2f79-4f24-a4fc-416eea8f138a&algo_expid=4c39b621-2f79-4f24-a4fc-416eea8f138a-2&btsid=0b0a050116016613800332457ea3fd&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
I never had a claim with BG, but shipping already was a disaster. I guess it would be a hard fight.
Or maybe sacrifice one of these STM32 developer boards? I got two here and they show the very same chip as in the picture you posted.
If you are able to replace the STM32 by the CB version then yes it's all good. I won't be able to do it personally as it's so small but if you can then sure it will work.
Yes it's small, and I'll probably bust it, but I guess it's my best chance. It will save me from going mad with BG support. It's probably easier to open a Paypal case. And: It's holiday season in China atm as well ...
Yes it's small, and I'll probably bust it, but I guess it's my best chance. It will save me from going mad with BG support. It's probably easier to open a Paypal case. And: It's holiday season in China atm as well ...
You might want to verify that the STM32 on the blue pill is genuine before you start. It's not uncommon for them to have cheap clones that have been screened to look like the genuine part.
If you hook it up with a USB-to-serial adapter you can try flashing a debug build of the multiprotocol firmware, which would tell you if the firmware sees the correct flash size via the serial console output. Or you could use Stm32flash or the STM32 Flash Demo Loader to verify that it's genuine by reading / writing it.
In any case, you will need to use a USB-to-serial adapter to flash it once and install the bootloader.
I guess I should have invested a bit more time before just swapping the STM32. I did it, and it looks decent. But I guess it needs a bootloader or something. I installed "multi flash" and installed the drivers, but there module is not recognized by windows.
The USB port won't work until you flash the bootloader. You need to do that with a USB-to-serial adapter. Once you hook the adapter up you also need to bridge the BOOT0 pins on the module.
Details are on the compiling page.
https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md
Oh yes 👍
Thanks a lot for your support. Next is a test in my Taranis :)
Looks good :)
I wonna give you something to LAUGH OUT LOUD. Guess what: I replaced a C8 with another C8 instead of a CB. How f***** stupid can someone be ;)
At least I still can run .59 and now order a CB to "repair" the module once again ;)
Looks good :)
How you did that. I also have the C8 processor. Please explain.
@Talha909. What do you mean? The programming (description is a few posts back) or hardware chip swap? If you ask about hardware I'm happy to help but, as you have to ask, it may be beyond your abilities/possibilities. You need a hot air station, twizzers, flux and a steady hand. And neelde probes to check against shorts after you flow soldered the new chip.
Nothing that can't be done, but it needs some experience. I definately would vote against it if you haven't done it before and also need to buy tools. Cheaper to get a replacement.
If you got any other questions and I can help with something specific please let me know :)
Does anyone know where I can find the original firmware? (since I flashed it before RTFM)
The original firmware was no better than force flashing a current one.
What do you mean by "original firmware"? Just flash an older one and you're set. Or compile a new one with reduced protocols.
Flashed multi-stm-opentx-taer-inv-v1.3.0.53.bin and it works. Just needed the D8.
Did anyone compile a smaller one that works? I can flash it by ignoring the 128KB message but I can't bind to anything :/
If you need to IGNORE a WARNING message than I'd say it's expected behaviour to not work.
Why don't you make a smaller version and try that one? Or replace the STM32 with the correct one?
If you need to IGNORE a WARNING message than I'd say it's expected behaviour to not work.
Why don't you make a smaller version and try that one? Or replace the STM32 with the correct one?
I just read above that you can flash the 110kB file but it can be random behaviour so I just tried it to confirm that the module worked at all :P I guess I should have dropped that. Anyways, I did compile a new one with only Futaba and DSM that I need for now and it was only 30kB. It still doesn't bind so maybe there's a user error involved here. Is it expected to say "No multi_telemetry" where it says "Module status" in the Taranis X9d?
You must add #define DISABLE_FLASH_SIZE_CHECK in your config file.
You must add #define DISABLE_FLASH_SIZE_CHECK in your config file.
that did the trick. I still had to leave the "disable flash size check" in flash multi to be able to flash it but now module status is showing the proper version and channel mapping. Will it be safe to fly with now that I flashed with a 30kB file on the 64kB C8 or should I still consider looking for a proper CB? The banggood ad said it was the 128KB but it for sure isn't when checking. I have a CB here that I compared it with and it's for sure a C8 chip on this module.
I'm working on an update to the Arduino IDE board package which will add an option to compile the firmware for the 64KB C8 MCU. It will move the EEPROM data section to the last 2KB of the first 64KB instead of at the last 2KB of the full 128KB of flash.
This is not full support for these modules - we will not be releasing 'official' 64KB firmware builds for them like we do for 128KB modules. The updated IDE board package will give people who know what they're doing the option of compiling firmware to run on a module with the C8 MCU, including DIY modules based on 'Blue Pill' development boards.
I expect to have the new board package released by the end of the week. It will need to be tested by people who have these modules and are ready/willing to configure and compile their own builds.
I got mine working by removing support for many protocols and adding the line pascallanger suggested above. I can compile and test this if it helps.
New Arduino boards have been released.
If you use the Arduino IDE to update your Multi boards you will have an option to compile firmware for a board with an STM32F103C8 MCU. The board definition will put the EEPROM in the right place for a 64KB board and will set the MCU flash size check appropriately for a 64KB board. You have 54KB available for firmware (64KB - 8KB bootloader - 2KB EEPROM).
Firmware version v1.3.1.77 is required when compiling for the new board. Older firmware versions won't have the updated MCU flash size check and won't run, even if compiled with this board.
New Arduino boards have been released.
If you use the Arduino IDE to update your Multi boards you will have an option to compile firmware for a board with an STM32F103C8 MCU. The board definition will put the EEPROM in the right place for a 64KB board and will set the MCU flash size check appropriately for a 64KB board. You have 54KB available for firmware (64KB - 8KB bootloader - 2KB EEPROM).
Great news. Since I got it working by reducing the total size what should I look for that isn’t working now and that this solves? I’ll do some testing later and report back if it works like the one I got.
Great news. Since I got it working by reducing the total size what should I look for that isn’t working now and that this solves? I’ll do some testing later and report back if it works like the one I got.
Your EEPROM data is still in the last two pages of the full 128KB flash. Using the new board guarantees that the EEPROM data is in the section of the flash space which is tested/supported. You also won't have to disable the MCU flash size check.
When I compiled a 55kB version of this newest 1.3.1.77 and selected the STM32F108C8 MCU I could flash without that warning as you said. It also doesn't show the "Multi-module EEPROM did not contain any data." after flashing like it did when I flashed with the 128kB STM32 chip. It works fine with the Futaba protocol and I can't spot any differences to the working version I had. I was prolly lucky with the EEPROM data before then but now it should be safer :) Thank you for the update. If there is any other specific things that you need me to check for bugs let me know and I'll test it the best I can.
Confirmed that at least two Jumper T16 Pro internal modules have now been identified as having the C8 64kb MCU.
Would it make sense to compile a list of affected modules? While this is not really a bug in mpm, it certainly is interesting information for (potential) end users of mpm. I can say that this bg module comes with the CB (so it is fine).
What we know of:
- URUAV TMX5
- URUAV TMX5 Lite
- Vantac MPM Lite
- Some Jumper T16 Pro internal modules
Also listed here:
https://www.multi-module.org/basics/module-hardware/unsupported-modules
Would it make sense to compile a list of affected modules? While this is not really a bug in mpm, it certainly is interesting information for (potential) end users of mpm. I can say that this bg module comes with the CB (so it is fine).
Several of the modules that now come with the wrong chip used to come with the right one, so you can't have a definite list, and those that come with the right one might also move to the wrong one unpredictably...
Apparently at least part of it is due to shortages of the correct chip.
Good afternoon. After reading the specifications of microcontrollers STM a little, I found a technical coincidence ...
3f103CB and 32f103RG using the RG series, we get a delay in reworking the system to a new level of the circuit ... in the RG series, the memory volume is 1MB in the RF series 768 kb? how hard is it to rebuild the firmware for these controllers?
Easy. As long as you have the same model with just more eeprom, I don't see a reason to rebuild the firmware at all?
I have the same problem, but the module chip seems to be the correct one. But I can't change it until the latest version.
Are they faking it with the right letters? I already complained to the seller about the defective display and it was difficult to win the dispute on aliexpress. Definitely complaining about this module update problem will give me even more work. I only managed to update 1.3.1.59 and get the message asking to update. And when I turn on the radio is warning a fail safe error.
@rodirib41 I do have a user on RCG reporting the exact same. It's the internal module of a Jumper T16, correct?
As a quick test, load the CC2500 64 firmware. If it works then yes the chip is fake and it's in fact a C8 with only 64KB of Flash...
@ rodirib41 Tenho um usuário no RCG relatando exatamente o mesmo. É o módulo interno de um Jumper T16, correto? Como um teste rápido, carregue o firmware CC2500 64. Se funcionar, então sim, o chip é falso e é na verdade um C8 com apenas 64 KB de Flash ...
thanks for your help. It worked. So that means I have a fake module, and a very fake one!
Now I have to settle for it. What am I going to stop using with this module? Can I have a module fault using this fake chip? Or is it worth buying another chip and replacing it?
The module will work reliablily but you need to compile the code by yourself to include just the protocols you need instead of all of them...
Compiling and selecting the protocols is really easy. You just need to try it.
Do you have a video that teaches you how to compile the code?
I'm sure someone must have done one...
But just following the documentation should do it: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md
Thank you very much!
@pascallanger Close issue maybe?
The information in this issue is now already in https://www.multi-module.org/basics/module-hardware/unsupported-modules
Hello,
I do not know exectly if this is the correct forum?
I bought a multi-module by banggoog a iRangeX . Which it is impossible to get it working.
I have a turnigy 9xr pro
Bootloader latest v3.0ready
Firmware ersky9x-P5r224
Firmware multi-module latest
According the instructions i installed the firmware etc.
The both led,s are on indicating all ok.
The problem is it will not bind to the receivers.
In the unit I found this processor
See picture a APM32F103CBT6