Update SPORT devices

[bsongis]

Discussion about the best way to implement SPORT devices update. I don't have the protocol right now.

[kilrah]

Mike has just been implementing it, so just need to integrate that. I'd say in the SD browser, like bootloader update?

[projectkk2glider]

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).

[bsongis]

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.

[bsongis]

Why a special mode, that's the question. I would also vote for SD Manager as André suggests.

[projectkk2glider]

Mike's words from http://www.rcgroups.com/forums/showpost.php?p=29135740&postcount=33189:

I've just updated the firmware on a X8R receiver.
What's special about doing that?
I did NOT use a computer!
The X8R was wired to the external module port on the Taranis and the firmware was flashed from a file on the SD card.
I just need to iron out a few minor things, but this feature will be in the next test version of ersky9x for Taranis.

It operates from the "maintenance mode" I have implemented in ersky9x. This is used to update the bootloader, for the original SKY board it can update the co-processor, and now on the Taranis it will be able to flash firmware to most, if not all, SPort devices that support firmware updating.
It needs to operate in a separate mode as it needs to take full control of the hardware to operate correctly.
("Maintenance mode" is entered by holding both horizontal trims AWAY from the centre while powering on.)

Some care does need to be taken in two areas.

1. The pins on the module connector are NOT in the correct order for the SPort, the power connections need to be swapped.
2. The Tx supplies the power for SPort device, and switches it on and off as required. Some Sport devices have a limited maximum voltage allowed, so if you are using a 3 cell lipo this may be too high a voltage.

Hopefully, this feature will get transferred to openTx.

Mike.

[MikeBland]

The text of an e-mail I just sent to Bertrand:
"I was never happy with updating the bootloader from the SD manager, I feel writing to the flash memory while actively running the main firmware could lead to problems.

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.
Users have got used to the trim use to get into bootloader mode, I don't think needing to hold them apart to get to maintenance mode is a real problem.

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.

[bsongis]

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.

[MikeBland]

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?
Why add code to stop everything and then restart it when you can just ignore it by never starting it in the first place?

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.

[kilrah]

If this was a computer I'd be proposing you run a different program to do this sort of update

Yet critical PC BIOS upgrades have been done on a running (Windows...) OS since about 10 years ago :)

I would always go for RELIABILITY over this "looks better" every time.

You're assuming that it's either reliability OR good looking. We aim for reliable AND good looking :)

We don't want users having failures to update firmware in devices.

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.

[MikeBland]

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.
I asked for users comments on RCG and have several positive responses to "maintenance mode" so I really don't see why openTx doesn't go that way, and use it.

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.

[kilrah]

I just never understand why this discussion needs to be happening.

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... ;)
It's not like we made a firmware that didn't work.

[Dvogonen]

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.

[ckleanth]

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.

[kilrah]

There is no maintenance mode in OpenTX. Porting that would be the option that takes more time.

[irun4fundotca]

+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

[kilrah]

?
Github is perfectly appropriate in this case. Developer discussion about an enhancement.

[bsongis]

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.

[MikeBland]

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:
// At this point, check for "maintenance mode"
if ( read_trims() == 0x81 )
{
// Do maintenance mode
#ifndef SIMU
CoInitOS();
MainTask = CoCreateTask( update_mode,NULL,5,&main_stk[MAIN_STACK_SIZE-1],MAIN_STACK_SIZE);
CoStartOS();
while(1) ;
#endif
}

Maintenance mode then calls whatever is needed to initialise the hardware it needs.

[MikeBland]

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.

[ckleanth]

mike can you make it available here?
http://openrcforums.com/forum/viewtopic.php?f=7&t=4582
(does it also include the countdown fix and gps speed fixes?)

[MikeBland]

I'll put a copy there, there is a copy here: http://openrcforums.com/forum/viewtopic.php?f=7&t=4676.
It does include the countdown fix, I don't think I know the gps speed fix, but I can look and try to add it.

[pindeslandes]

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:
I don’t think a user has to care at all about the meaning of such technical terms as firmware, eeprom, bootloader or even SD card, as long as all what he has to deal with is properly documented. Personally, I also don’t need to pretend to understand what is happening when I update the firmware or why I am asked to update the bootloader: I just do as in the manual without figuring what’s going on in the guts of my radio, since, as a confident user, I am sure that it will work fine.
So I see no reason why I shouldn’t be OK with having three modes (an ‘operating mode’, an ‘update firmware mode’ and an ‘update anything else mode’, as I understand). But I would be OK with two modes two!

SPORT device update:
I hardly understand where is the advantage of being able to update a device without a computer because, since the firmware is flashed from a file on the SD card, you need a computer to put the relevant file on the SD card, don’t you. In addition, with a computer, I guess you would have to plug the device somehow to the USB port, which I suppose eliminate any voltage issue. But maybe it is because I haven’t tried to update any device with any computer yet…

Did I say “properly documented” and “as in the manual” somewhere?
Surely it’s the Achilles’ heel of OpenTx. I am aware that a lot have been done and that work is in progress (I red #1077 which has a 2.1 milestone) but, in my opinion, having an up to date documentation of 2.0 is more important and more urgent than developing 2.1, and even maybe a prerequisite to 2.1.
Two reasons:

1. A good documentation means no more (or a lot less) irrelevant issues or silly questions from people who can’t guess how their radio works (so many questions like “Is it the way it is intended to be?”).
2. A good documentation also means smarter users and more relevant issues, so that it would be easier for you to figure out what is important to put in the next version.
   Also I would be glad to help writing some piece of documentation but I’m afraid it would need to much guess work from me (and that my English isn’t fair enough!).

[ckleanth]

@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.
re documentation, did you read the all documentation available?
90% of users don't RTFM, then complain things don't work. However OpenTx 2.0+ has changed and still changes, Kilrah's document covers the changes perhaps its easier to update that with all recent changes
If you have time to help with documentation, please do so, your English seems ok to me.

[MikeBland]

@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.

[nigelsheffield]

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.
I updated my vario and internal rf module through windows PC and it went fine but I did have to think about it to get the right programs and f/w and make the right connection, anyone prepared to do this would be capable of entering the maintenance mode.
Which is easiest/best for devs?

[pindeslandes]

@MikeBland thank you for you answer, now I understand that updating a device without a computer would be a very nice feature!

[Scott-Page]

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.

[bsongis]

@Scott-Page 9XR-PRO users who install OpenTX will use Mike's bootloader, no difference here!

[kilrah]

Not working though.
Serial data looks inverted (need to check Mike's stuff to see if an inverter was required but I don't remember it), and I only see (broken) 2-byte packets sent during discovery instead of 10-byte standard SPORT packets.

[MikeBland]

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.
For something like firmware update I would strongly recommend running only the code needed to minimise any possibility of the update failing.

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 )
{
SportTx.ptr = buffer ;
SportTx.count = count ;
GPIOD->BSRRL = 0x0010 ; // output enable
USART2->CR1 &= ~USART_CR1_RE ; // Turn off receiver
USART2->CR1 |= USART_CR1_TXEIE ;
}

extern "C" void USART2_IRQHandler()
{
uint32_t status;
uint8_t data;

status = USART2->SR ;

if ( status & USART_SR_TXE )
{
    if ( SportTx.count )
    {
        USART2->DR = *SportTx.ptr++ ;
        if ( --SportTx.count == 0 )
        {
            USART2->CR1 &= ~USART_CR1_TXEIE ;   // Stop Tx interrupt
            USART2->CR1 |= USART_CR1_TCIE ; // Enable complete interrupt
        }
    }
}

if ( ( status & USART_SR_TC ) && (USART2->CR1 & USART_CR1_TCIE ) )
{
    USART2->CR1 &= ~USART_CR1_TCIE ;    // Stop Complete interrupt
    GPIOD->BSRRH = 0x0010 ;     // output disable
    USART2->CR1 |= USART_CR1_RE ;
while (status & (USART_FLAG_RXNE))
    {
    status = USART2->DR;
    status = USART2->SR ;
    }
}

while (status & (USART_FLAG_RXNE | USART_FLAG_ERRORS))
{
data = USART2->DR;

if (!(status & USART_FLAG_ERRORS))
    {
        put_fifo64( &Telemetry_fifo, data ) ;
    }
    else
    {
        USART_ERRORS += 1 ;
        if ( status & USART_FLAG_ORE )
        {
            USART_ORE += 1 ;
        }
        if ( status & USART_FLAG_NE )
        {
            USART_NE += 1 ;
        }
        if ( status & USART_FLAG_FE )
        {
            USART_FE += 1 ;
        }
        if ( status & USART_FLAG_PE )
        {
            USART_PE += 1 ;
        }
    }
status = USART2->SR ;

}
}

This works reliably on a running Tx as well as SPort update.

Mike.

[rc-smurf]

Is this going into 2.0.16 as well? Issue closed but code only committed to next...

[janekx]

I suggest to change the order of the menu, first external and then internal flash command ....
Most time will be flashed external devices then internal XJT and in case of playing around not possible to bad flash internal module. Is there some protection to not flash FW to not corresponding device?
Tested on old T and it works OK

[MikeBland]

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.
While running this update code you MUST make sure nothing holds the "end of transmission" interrupt off for any length of time.
I can see, on my 'scope, an occurance where the first start bit from the updating device has been cut because the output enable signal was still active.

Mike.

[projectkk2glider]

I am reopening this ticket, two reasons:

• Mike's comment above (end of transmission bug)
• the need to include this in OpenTX 2.0.16

[bsongis]

About the need to include this in 2.0.16, we are in the process of releasing an alpha for 2.1!

[kilrah]

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).

[MikeBland]

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.
On ersky9x, I have set most interrupts to be level 4, one or two are set lower. I now have the 5mS timer set at 3, needed to be higher than the general 4 for the audio output, the end of transmission is 2, and I have a software driven serial driver, to handle non-inverted serial on pin 5 of the module connector with the interrupt level at 1 as this is absolutely critical. It shouldn't be used with the updating code so shouldn't cause any problems.

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.

[griebd]

Adding this feature as "maintenance mode" (trims held apart at power on) is quick and easy, only
takes 10 minutes to do the changes.

I do agree with @MikeBland on that.... Just my 2 cents... 😉

[janekx]

I agree for separate "maintenance mode". Flashing should be most safe how much is possible so OS independent.

[neckisch]

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.
So why not doing it as in ErSky and lets see what users will say. if it is to confusing, lets implement another way.

[seancull]

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.

[kilrah]

Why is this still open? Smart port device flashing is already in 2.1.0 that is about to be released.

[fraternl]

Wasn't clear to me either...
I thought you might still want to move it to the startup code (trims held apart) for stability reasons.
But I've seen it in the SD card manager.
I might need it soon to retro-flash an X4R-receiver I am considering to buy

[tonimerlot]

Sorry but not understand if It is programmed added firmware upgrade of SPORT devices on OpenTX 2.0 branch?

[janekx]

No only 2.1

[MikeBland]

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