-
-
Notifications
You must be signed in to change notification settings - Fork 812
Update SPORT devices #1599
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
Comments
Mike has just been implementing it, so just need to integrate that. I'd say in the SD browser, like bootloader update? |
I've read Mike's announcement and he says that hw must be put in special mode to allow programming. So ti might be impossible from opentx. He talks about maintenance mode (probably of bootloader). |
I received a direct mail from Mike, that's why I just opened this issue as he asked me if I was going to implement it the same way than him. |
Why a special mode, that's the question. I would also vote for SD Manager as André suggests. |
Mike's words from http://www.rcgroups.com/forums/showpost.php?p=29135740&postcount=33189:
|
The text of an e-mail I just sent to Bertrand: I don't think there will be enough space in the bootloader to add this, partly why I have maintenance mode. Ersky9x users seem quite happy with "maintenance mode" for both the bootloader update and, on the SKY boards, to do a co-processor update. Trying to do this update from within the main code could be quite tricky. It needs to stop just about all other activity - e.g. PPM/PXX output, telemetry input, SD card access so no voice or logging etc. It is just so much easier if it runs in a standalone mode, as I have it working. I suggested this to FrSky a while ago and they sent me both the protocol and windows program source code. The update sends packets both ways over the SPort, 2 10-byte packets for each 32-bit word to be written. This means it is quite slow, a maximum of 1152 flash bytes per second. Anything else running is very likely to slow this down. I already had to deal with the display refresh taking up many milliseconds and blocking the update. This really is something that needs to be done in a controlled fashion. We don't want users having failures to update firmware in devices. I would always go for RELIABILITY over this "looks better" every time. I wouldn't suggest doing it this way unless I felt it was necessary." I've already given this quite a bit of thought. Doing this from within the main running firmware is, in my opinion, open to too many possibilities of it going wrong. |
The difference between a firmware and an eeprom doesn't sound evident for the avarage Taranis users... so firmware, bootloader, maintenance, why 3 modes, I can't imagine. I would like having it in the bootloader but perhaps you are right with the flash space problem. So I am rather for the SD Manager solution, stopping everything as you say and starting again everything at the end of the update. |
I still don't agree. Can you be sure you have stopped everything? Can you be sure something that would need to be stopped isn't added in the future, but NOT stopped. To avoid code duplication I make use of existing routines that need to be started in a controlled way (e.g. FrSky SPort telemetry receive). What I have working IS working and will need very little done to integrate it in, why consider re-writing it? As previously, I can see too many possibilities of things going wrong. We had the situation of changing to only one trim to enter the bootloader until I pointed out the danger of loss of control. Please consider what I'm proposing is based on a lot of experience of this sort of thing, just keep it simple. If this was a computer I'd be proposing you run a different program to do this sort of update, so maintenance mode is about as close as we can get. |
Yet critical PC BIOS upgrades have been done on a running (Windows...) OS since about 10 years ago :)
You're assuming that it's either reliability OR good looking. We aim for reliable AND good looking :)
Uh... remember FrSky's own update program BSOD's users' computers about half of the time, which not only screws up the firmware on the device but can obviously also lead to data loss on the PC, which is orders of magnitude worse. Can't do much worse even if we tried hard to. Sensors are unbrickable anyway. |
I just never understand why this discussion needs to be happening. I'm using years of experience of dealing with this sort of thing and just 'know' of all sorts of pitfalls. This is why I opted for "maintenance mode" in the first place. In addition, I originally described "maintenance mode" to FrSky when I first contacted them regarding this possibility. They seemed to like it, and subsequently sent me the details required to implement the SPort device update. |
Me either. Why we can't just do the things as we see fit without spending 3 days arguing about them is a bit beyond me... ;) |
Regardless of which implementation is easiest to use and looks the prettiest, it is far better for the users if the exact same functionality is implemented in the same way in OpenTX /ersky9x. This saves them confusion and us time. There are already a lot of things that must look and work differently. No need to spend development time on creating more diversion without a functional reason for doing so. |
KISS, From a users point of view I echo Mike's and Kjell's comments... Opentx dev team have Mike's source code and it works, the implementation of firmware, bootloader, and maintenance mode is the same in both opentx and ersky9x so no user/usability headaches here, plus Opentx Dev team have more time to focus on other stuff. |
There is no maintenance mode in OpenTX. Porting that would be the option that takes more time. |
+1 kilrah these posts should be discussed more in a thread not on github, I see more posts daily that are more discussions than actual real problem submissions |
? |
My opinion, it's better to discuss before starting devs, that's why I opened this issue. Also I am looking for the best solution from the user point of view, not the developer. If ersky9x way is the best then I will have more time for other things, but I am not sure it's the case. |
Adding maintenance mode should be quite easy. Most of the code is self contained. All I do is add the following code in main before starting the OS normally: Maintenance mode then calls whatever is needed to initialise the hardware it needs. |
By using openTx r2904 (I'm still running that on my production Taranis), I've ported maintenance mode to openTx. I'll be sending a .zip file of the changes. I've tested this change and it all works, and flashes SPort devices. I believe the changes for openTx 2.0.8 are as straightforward. |
mike can you make it available here? |
I'll put a copy there, there is a copy here: http://openrcforums.com/forum/viewtopic.php?f=7&t=4676. |
May be some users’ opinions would help. Here is mine. First of all, I wish to thank and congratulate you all, contributors, for your amazing work. Maintenance mode: SPORT device update: Did I say “properly documented” and “as in the manual” somewhere?
|
@pindeslandes if you haven't tried or had to update any sport enabled device then I don't know why you post here. Updating frsky devices is a pain on the buttocks especially having to use a "make ends meet" type program to upload the firmware. then it doesn't allays work, meaning you need to play with the com port to get communication out. If we had a standardised and stable method to update the firmware, I'd take it. |
@pineslades. The update PC program is, as far as I know, only avalable for Windows. Linux and MAC users don't have a way to do these updates. Also, there are users who provide a service to others in their flying clubs. Being able to update others SPort devices at the flying field is very useful to them. |
As user I would not mind either way, but if there is a potential problem with doing it through SD browser in the future then maintainence mode sounds a safer bet, it would be no more awkward then the 2 trims we have now and is something that will be needed a LOT less anyway. |
@MikeBland thank you for you answer, now I understand that updating a device without a computer would be a very nice feature! |
It would sure be alot easier to support folks if Sport updates in OpentX and ersky9x were the same. I just read a brand new "lesson" on bootloaders on OpenTXU and I see that there will be problems with it.. http://open-txu.org/home/undergraduate-courses/fund-of-opentx/part-3-understanding-boot-loaders/ Wanna guess? Ya - the author didn't include reference to the FIRMWARE vs FIRMWARES which was another rediculious difference. I can already foresee the questions on this lesson coming from 9XR users who install OpenTX. |
@Scott-Page 9XR-PRO users who install OpenTX will use Mike's bootloader, no difference here! |
Not working though. |
Could be caused by running in the wrong environment, i.e. fully operating Tx instead of maintenance mode where only the update code is running. I can't see any maintenance mode only code. NOTE: I built an openTx.bin from the master branch with "maintenance mode" in it and it all worked. That's the code is passed over. Since the SPort receives what is sent, receive data is probably shutting down the transmit operation. I have updated my code to the following so I can use the SPort for a different purpose. It turns the receive off while transmitting, and also only actions the TC interrupt if it is enabled. void x9dSPortTxStart( uint8_t *buffer, uint32_t count ) extern "C" void USART2_IRQHandler() status = USART2->SR ;
while (status & (USART_FLAG_RXNE | USART_FLAG_ERRORS))
} This works reliably on a running Tx as well as SPort update. Mike. |
Is this going into 2.0.16 as well? Issue closed but code only committed to next... |
I suggest to change the order of the menu, first external and then internal flash command .... |
I'm getting a problem on the 9XR-PRO where the update fails sometimes. I've tracked this down to, most likely, the SPort output not being disabled soon enough after the end of transmission. Just occasionally it occurs much later than at other times. Also the updating device responds very quickly, sometimes as soon as around 18uS after the end of the stop bit last sent to it. Mike. |
I am reopening this ticket, two reasons:
|
About the need to include this in 2.0.16, we are in the process of releasing an alpha for 2.1! |
Yes but there are some people who will never want to update to 2.1 as there will be very big changes. On 2.1 I have updated things a couple of dozen times and never had a failure. I however started a port to master and there I have the same issues as Mike, and what I saw with the LA could match (when it fails the radio is the last to send a packet, and never receives an answer from the device i.e. maybe the device is trying to talk but the line level is still being forced by the radio, so it gives up). |
…r won't even start. An XJT in the module slot upgrades fine. #1599
I found my problem on the 'PRO, the 5mS timer interrupt was a higher priority than the end of transmission interrupt. I changed the 5mS to be lower priority and all is fine. I can see the transfer is now exact on my 'scope. I did 8 firmware updates with no failures. Adding this feature as "maintenance mode" (trims held apart at power on) is quick and easy, only takes 10 minutes to do the changes. Mike. |
I do agree with @MikeBland on that.... Just my 2 cents... 😉 |
I agree for separate "maintenance mode". Flashing should be most safe how much is possible so OS independent. |
as there is a new etsi norm for european users to be adhered, the maintenance mode becomes more interesting. i want to downgrade my taranis back to the non EU tx module firmware due to receiver compatibility issues. therefore it would be really helpful to have a feature like this in openTX. |
I flashed some receivers over the weekend and had to revert to an earlier version of the FRSky firmware tool that I was fortunate enough to have saved. The posted one did not work - not red progress "LEDs" in the UI and no response from the receiver. It would be great to have this although I would agree with the comments about the whole firmware thing being very confusing to normal users. |
Why is this still open? Smart port device flashing is already in 2.1.0 that is about to be released. |
Wasn't clear to me either... |
Sorry but not understand if It is programmed added firmware upgrade of SPORT devices on OpenTX 2.0 branch? |
No only 2.1 |
For a straightforward build of openTx 2.0.x, I've posted some binaries I built that include "maintenance mode", together with the changed.added source files if you need to build openTx yourself. You may find them here: http://openrcforums.com/forum/viewtopic.php?f=45&t=6847&hilit=sport+device+updating |
Discussion about the best way to implement SPORT devices update. I don't have the protocol right now.
The text was updated successfully, but these errors were encountered: