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

Update SPORT devices #1599

Closed
bsongis opened this Issue Aug 10, 2014 · 58 comments

Comments

Projects
None yet
@bsongis
Member

bsongis commented Aug 10, 2014

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

@kilrah

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Aug 10, 2014

Member

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

Member

kilrah commented Aug 10, 2014

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

@projectkk2glider

This comment has been minimized.

Show comment
Hide comment
@projectkk2glider

projectkk2glider Aug 10, 2014

Member

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

Member

projectkk2glider commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Aug 10, 2014

Member

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.

Member

bsongis commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Aug 10, 2014

Member

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

Member

bsongis commented Aug 10, 2014

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

@projectkk2glider

This comment has been minimized.

Show comment
Hide comment
@projectkk2glider

projectkk2glider Aug 10, 2014

Member

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.

Member

projectkk2glider commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 10, 2014

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.

MikeBland commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Aug 10, 2014

Member

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.

Member

bsongis commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 10, 2014

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.

MikeBland commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Aug 10, 2014

Member

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.

Member

kilrah commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 10, 2014

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.

MikeBland commented Aug 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Aug 11, 2014

Member

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.

Member

kilrah commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Dvogonen

Dvogonen Aug 11, 2014

Contributor

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.

Contributor

Dvogonen commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ckleanth

ckleanth Aug 11, 2014

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.

ckleanth commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Aug 11, 2014

Member

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

Member

kilrah commented Aug 11, 2014

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

@irun4fundotca

This comment has been minimized.

Show comment
Hide comment
@irun4fundotca

irun4fundotca Aug 11, 2014

+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

irun4fundotca commented Aug 11, 2014

+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

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Aug 11, 2014

Member

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

Member

kilrah commented Aug 11, 2014

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

@bsongis

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Aug 11, 2014

Member

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.

Member

bsongis commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 11, 2014

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 commented Aug 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 13, 2014

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.

MikeBland commented Aug 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ckleanth

ckleanth Aug 13, 2014

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

ckleanth commented Aug 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 14, 2014

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.

MikeBland commented Aug 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@pindeslandes

pindeslandes Aug 15, 2014

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

pindeslandes commented Aug 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ckleanth

ckleanth Aug 15, 2014

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

ckleanth commented Aug 15, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Aug 15, 2014

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

MikeBland commented Aug 15, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@nigelsheffield

nigelsheffield Aug 15, 2014

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?

nigelsheffield commented Aug 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@pindeslandes

pindeslandes Aug 16, 2014

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

pindeslandes commented Aug 16, 2014

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

@Scott-Page

This comment has been minimized.

Show comment
Hide comment
@Scott-Page

Scott-Page Aug 17, 2014

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 commented Aug 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Aug 25, 2014

Member

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

Member

bsongis commented Aug 25, 2014

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

@bsongis bsongis added this to the OpenTX 2.1 milestone Aug 25, 2014

@WZ9V

This comment has been minimized.

Show comment
Hide comment
@WZ9V

WZ9V Sep 4, 2014

This functionality sounds like a great idea. Especially for someone like me who would prefer not having to boot back into Windows to update devices. I would prefer having two modes rather than three but it don't sacrifice reliability. As a user I get the heebie-jeebies when ever a flash update goes wrong and I have to redo it several times to get it to take. As a former programmer of some embedded devices I totally get the timing issues and why the OS could be a problem. That is why I' sure FrSky jumped on this as a good idea. Loaders within the OS environment are a major pain to get right. This is a function I wouldn't anticipate doing all that often so documenting it and making it easy to follow would be important.

WZ9V commented Sep 4, 2014

This functionality sounds like a great idea. Especially for someone like me who would prefer not having to boot back into Windows to update devices. I would prefer having two modes rather than three but it don't sacrifice reliability. As a user I get the heebie-jeebies when ever a flash update goes wrong and I have to redo it several times to get it to take. As a former programmer of some embedded devices I totally get the timing issues and why the OS could be a problem. That is why I' sure FrSky jumped on this as a good idea. Loaders within the OS environment are a major pain to get right. This is a function I wouldn't anticipate doing all that often so documenting it and making it easy to follow would be important.

@tedbmoss

This comment has been minimized.

Show comment
Hide comment
@tedbmoss

tedbmoss Nov 26, 2014

I as a "user" agree that the maintenance mode would be best.
Regards, Ted

tedbmoss commented Nov 26, 2014

I as a "user" agree that the maintenance mode would be best.
Regards, Ted

@fraternl

This comment has been minimized.

Show comment
Hide comment
@fraternl

fraternl Jan 13, 2015

Contributor

From a user's viewpoint this flashing using the bootloader feels correct and confirms you're doing something special.
Documentation is already needed (the reverse polarity of the cable)

Contributor

fraternl commented Jan 13, 2015

From a user's viewpoint this flashing using the bootloader feels correct and confirms you're doing something special.
Documentation is already needed (the reverse polarity of the cable)

@bsongis bsongis modified the milestones: OpenTX 2.0.15, OpenTX 2.1 Jan 13, 2015

@MikeBland

This comment has been minimized.

Show comment
Hide comment

@bsongis bsongis modified the milestones: OpenTX 2.0.16, OpenTX 2.0.15 Jan 13, 2015

@bsongis

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Jan 13, 2015

Member

We have to release OpenTX 2.0.15 tonight, this one will be added to 2.0.16 as soon as 2.0.15 is ready. Thanks Mike for the code.

Member

bsongis commented Jan 13, 2015

We have to release OpenTX 2.0.15 tonight, this one will be added to 2.0.16 as soon as 2.0.15 is ready. Thanks Mike for the code.

@er9xuser

This comment has been minimized.

Show comment
Hide comment
@er9xuser

er9xuser Jan 21, 2015

@rc-smurf yes you can. I've flashed internal module yesterday with ersky9x fw for taranis. It's easy.

er9xuser commented Jan 21, 2015

@rc-smurf yes you can. I've flashed internal module yesterday with ersky9x fw for taranis. It's easy.

@fraternl

This comment has been minimized.

Show comment
Hide comment
@fraternl

fraternl Jan 23, 2015

Contributor

Issue 2001 got closed because it was supposedly a duplicate of this one.
This is not true.
"Issue 2001" is about updating the parameters of S-Port devices. NOT updating the firmware.
It was more of a reminder for Mike Blandford as he more or less proposed to do it (if he finds the time)

#2001

Can it please be reopened or at least get a comment why it has to stay closed?

Contributor

fraternl commented Jan 23, 2015

Issue 2001 got closed because it was supposedly a duplicate of this one.
This is not true.
"Issue 2001" is about updating the parameters of S-Port devices. NOT updating the firmware.
It was more of a reminder for Mike Blandford as he more or less proposed to do it (if he finds the time)

#2001

Can it please be reopened or at least get a comment why it has to stay closed?

@kilrah

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Jan 24, 2015

Member

It goes together, we'll just integrate Mike's code with the functionality it has.

Member

kilrah commented Jan 24, 2015

It goes together, we'll just integrate Mike's code with the functionality it has.

@bsongis

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Feb 6, 2015

Member

I will integrate Mike's code into 'master', but I would like to have this version in 'next'

Member

bsongis commented Feb 6, 2015

I will integrate Mike's code into 'master', but I would like to have this version in 'next'

@janekx

This comment has been minimized.

Show comment
Hide comment
@janekx

janekx Feb 9, 2015

I am ready to test :)

janekx commented Feb 9, 2015

I am ready to test :)

@projectkk2glider

This comment has been minimized.

Show comment
Hide comment
@projectkk2glider

projectkk2glider Feb 21, 2015

Member

Except for one comment, the code looks good to the eye.

Member

projectkk2glider commented Feb 21, 2015

Except for one comment, the code looks good to the eye.

@kilrah

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Feb 23, 2015

Member

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.

Member

kilrah commented Feb 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Feb 23, 2015

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.

MikeBland commented Feb 23, 2015

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.

@bsongis bsongis closed this in fdb4852 Mar 14, 2015

@rc-smurf

This comment has been minimized.

Show comment
Hide comment
@rc-smurf

rc-smurf Mar 19, 2015

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

rc-smurf commented Mar 19, 2015

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

@kilrah kilrah modified the milestones: OpenTX 2.1, OpenTX 2.0.16 Mar 20, 2015

@janekx

This comment has been minimized.

Show comment
Hide comment
@janekx

janekx Mar 23, 2015

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

janekx commented Mar 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Mar 23, 2015

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.

MikeBland commented Mar 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@projectkk2glider

projectkk2glider Mar 23, 2015

Member

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
Member

projectkk2glider commented Mar 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@bsongis

bsongis Mar 23, 2015

Member

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

Member

bsongis commented Mar 23, 2015

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

@kilrah

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Mar 24, 2015

Member

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

Member

kilrah commented Mar 24, 2015

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

kilrah added a commit that referenced this issue Mar 24, 2015

External module flashing now reliable, internal one of my Plus howeve…
…r won't even start. An XJT in the module slot upgrades fine. #1599
@MikeBland

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Mar 24, 2015

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.

MikeBland commented Mar 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@griebd

griebd Mar 24, 2015

Member

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

Member

griebd commented Mar 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@janekx

janekx Mar 24, 2015

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

janekx commented Mar 24, 2015

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

@neckisch

This comment has been minimized.

Show comment
Hide comment
@neckisch

neckisch Jul 6, 2015

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.

neckisch commented Jul 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@seancull

seancull Jul 6, 2015

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.

seancull commented Jul 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kilrah

kilrah Jul 6, 2015

Member

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

Member

kilrah commented Jul 6, 2015

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

@kilrah kilrah closed this Jul 6, 2015

@fraternl

This comment has been minimized.

Show comment
Hide comment
@fraternl

fraternl Jul 7, 2015

Contributor

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

Contributor

fraternl commented Jul 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tonimerlot

tonimerlot Feb 21, 2016

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

tonimerlot commented Feb 21, 2016

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

@janekx

This comment has been minimized.

Show comment
Hide comment
@janekx

janekx Feb 21, 2016

No only 2.1

janekx commented Feb 21, 2016

No only 2.1

@MikeBland

This comment has been minimized.

Show comment
Hide comment
@MikeBland

MikeBland Feb 21, 2016

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

MikeBland commented Feb 21, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment