-
-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules with STM32F103C8 MCUs are not supported in release builds (e.g. URUAV TMX5, VANTAC, etc.) #393
Comments
I can confirm that this also applies to the URUAV TMX5 Lite variant. Same MCU, same 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. |
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? 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 |
Thanks for clarification and F*CK. :( I never had a claim with BG, but shipping already was a disaster. I guess it would be a hard fight. |
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 ... |
If I deselect some protocols that are not needed. And get the size below 64k will it work.
Fabio Ehrengruber
[email protected]
… On Oct 2, 2020, at 10:44 AM, Ben Lye ***@***.***> wrote:
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.
<https://user-images.githubusercontent.com/23322579/94953293-38143a80-04df-11eb-94a0-5e645d40ff4d.jpg>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#393 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIFQ5CPFCM3EDBF5KSQQXJ3SIYGRVANCNFSM4O6H7MQA>.
|
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. |
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 |
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 ;) |
@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. |
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. |
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:
Also listed here: |
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 ... |
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? |
@rodirib41 I do have a user on RCG reporting the exact same. It's the internal module of a Jumper T16, correct? |
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... |
Do you have a video that teaches you how to compile the code? |
I'm sure someone must have done one... |
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 |
This module is using wrong components with the majors being:
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).
The text was updated successfully, but these errors were encountered: