Tx Reset when using Flysky protocol

Start
Prev
1
Next
End

ColdFire
Topic Author
Offline

18 Mar 2013 18:35 #7892 by ColdFire

Tx Reset when using Flysky protocol was created by ColdFire

Not sure if the root cause has been identified. From what I understand it is more likely that the program get stucked in spi_read function, and I suspect that it is the CS line that causes the problem. so I add a little bit delay after pulling the CS line low:

#define CS_LO() gpio_clear(GPIOA, GPIO13); \
usleep(1)

which seems to solve the problem for me. the delay time could be shorter though (have not tested that yet).

Please Log in or Create an account to join the conversation.

domcars0
Offline

18 Mar 2013 19:21 #7894 by domcars0

Replied by domcars0 on topic Tx Reset when using Flysky protocol

I think PB has fixed the bug, but it's still not corrected in his repo ...
Read his conversation with sbstnp here :
bitbucket.org/PhracturedBlue/deviation/i...sky-protocol-reboots

Devo 10 (+7e) owner. It's mine, please don't touch it with your big fingers

Please Log in or Create an account to join the conversation.

ColdFire
Topic Author
Offline

18 Mar 2013 19:36 #7895 by ColdFire

Replied by ColdFire on topic Tx Reset when using Flysky protocol

Good to know! Thanks for the info.

Please Log in or Create an account to join the conversation.

PhracturedBlue
Offline

18 Mar 2013 19:42 #7896 by PhracturedBlue

Replied by PhracturedBlue on topic Tx Reset when using Flysky protocol

Please try the fix I proposed to sbstnp.
I would like to know if it fixes your issue as well, or if I need to do something additional. That fix can't be released as is as it won't work for the devo7e, but hopeulfly with some more experimentation we can finde something that works everywhere

Please Log in or Create an account to join the conversation.

ColdFire
Topic Author
Offline

18 Mar 2013 19:49 #7897 by ColdFire

Replied by ColdFire on topic Tx Reset when using Flysky protocol

I'll apply the fix whenever I got home.
The problem is on the come-and-go basis. sometime it resets Tx every time, other time the whole thing just run stable.
There is one time I narrowed down the problem to the change to some file (clock.c and syscalls.c). use older version of these two files with new revision will make the problem go away. though I never come up with an explanation for that.
yesterday I was applying some change to the source code and the trick does not work anymore

, then I started to play with SPI_read function and found the adding of delay did the trick.

PhracturedBlue wrote: Please try the fix I proposed to sbstnp.
I would like to know if it fixes your issue as well, or if I need to do something additional. That fix can't be released as is as it won't work for the devo7e, but hopeulfly with some more experimentation we can finde something that works everywhere

Please Log in or Create an account to join the conversation.

sbstnp
Offline

18 Mar 2013 19:54 #7899 by sbstnp

Replied by sbstnp on topic Tx Reset when using Flysky protocol

ColdFire wrote: Not sure if the root cause has been identified. From what I understand it is more likely that the program get stucked in spi_read function, and I suspect that it is the CS line that causes the problem. so I add a little bit delay after pulling the CS line low:

#define CS_LO() gpio_clear(GPIOA, GPIO13); \
usleep(1)

which seems to solve the problem for me. the delay time could be shorter though (have not tested that yet).

This doesn't work on my Devo 10. Still get reboots.

Devo 10 + 4in1
~~Spektrum Dx9~~
FrSky Taranis + TBS Crossfire

Please Log in or Create an account to join the conversation.

ColdFire
Topic Author
Offline

18 Mar 2013 20:12 #7901 by ColdFire

Replied by ColdFire on topic Tx Reset when using Flysky protocol

too bad, sounds there is no silver bullet ...

sbstnp wrote:
ColdFire wrote: Not sure if the root cause has been identified. From what I understand it is more likely that the program get stucked in spi_read function, and I suspect that it is the CS line that causes the problem. so I add a little bit delay after pulling the CS line low:

#define CS_LO() gpio_clear(GPIOA, GPIO13); \
usleep(1)

which seems to solve the problem for me. the delay time could be shorter though (have not tested that yet).

This doesn't work on my Devo 10. Still get reboots.

Please Log in or Create an account to join the conversation.

ColdFire
Topic Author
Offline

19 Mar 2013 05:33 - 19 Mar 2013 20:40 #7913 by ColdFire

Replied by ColdFire on topic Tx Reset when using Flysky protocol

I confirm that the fix I mentioned earlier does not work with the newest revision (It only works with older revision). PB's solution does work!

Here comes another fix I have:
add 1us delay (after the spi_xfer) in A7105_ReadReg:

u8 A7105_ReadReg(u8 address)
{
u8 data;
int i;
CS_LO();
spi_xfer(SPI2, 0x40 | address);
usleep(1);
spi_disable(SPI2);
spi_set_bidirectional_receive_only_mode(SPI2);
spi_enable(SPI2);
for(i = 0; i < 10; i++)
;
spi_disable(SPI2);
data = spi_read(SPI2);
CS_HI();
spi_set_unidirectional_mode(SPI2);
spi_enable(SPI2);
return data;
}

It works fine for me so far. I also tried to reload the model for more than 20 times and it seems to be fairly stable. The delay after 7105 reset seems to be less strict in this case: either 10000us or 100000us works.

sbstnp wrote:
ColdFire wrote: Not sure if the root cause has been identified. From what I understand it is more likely that the program get stucked in spi_read function, and I suspect that it is the CS line that causes the problem. so I add a little bit delay after pulling the CS line low:

#define CS_LO() gpio_clear(GPIOA, GPIO13); \
usleep(1)

which seems to solve the problem for me. the delay time could be shorter though (have not tested that yet).

This doesn't work on my Devo 10. Still get reboots.

Last edit: 19 Mar 2013 20:40 by ColdFire.

Please Log in or Create an account to join the conversation.

PhracturedBlue
Offline

21 Mar 2013 04:44 - 21 Mar 2013 04:46 #7944 by PhracturedBlue

Replied by PhracturedBlue on topic Tx Reset when using Flysky protocol

I did a bunch of experimentation. Unfortunately my devo8 rarely locks up with the Flysky/hubsan protocols, but I was able to get some decent testing in. As Coldfilre speculated, the problem seems to be that spi_read hangs forever. I believe this is because the SPI read is never started (and thus never finishes). The STM32 has a rather odd interface to reading in 3-wire mode. you need to hold the spi enabled for more than 1 SPI clock and less than 8. The 'for()' loop was supposed to do that, but it is getting optimized out, so we aren't holding the enable long enough to guarantee that a read works.

I have checked in tweaked code which follows the Refernece Manual with respect to transmit and receive. It seems to work well for me, but I'd like everyone with issues to try the latest code and report back. If you get reboots, please provide the elf and errors.txt file. These are really helpful in letting me see what is going on.

Additionally I may not have been waiting long enough for the transmit to complete before shutdown, so I properly checked that too.

Last edit: 21 Mar 2013 04:46 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

sbstnp
Offline

21 Mar 2013 05:20 #7945 by sbstnp

Replied by sbstnp on topic Tx Reset when using Flysky protocol

Thanks, will test when I get home and report back.

Devo 10 + 4in1
~~Spektrum Dx9~~
FrSky Taranis + TBS Crossfire

Please Log in or Create an account to join the conversation.

vlad_vy
Offline

21 Mar 2013 13:17 #7954 by vlad_vy

Replied by vlad_vy on topic Tx Reset when using Flysky protocol

At least, with Hubsan protocol all work fine. Thanks.

Please Log in or Create an account to join the conversation.

ColdFire
Topic Author
Offline

22 Mar 2013 04:33 #7987 by ColdFire

Replied by ColdFire on topic Tx Reset when using Flysky protocol

I have not try it but the explanation makes perfect sense to me now. since the only place that could get watchdog overflow is waiting for tx/rx flags and rx is the most suspicious one (the rx code looks really confusing at the first glance and it only makes some sense after reading the datasheet). Actually, since MCU is the SPI master, the SPI xfer should always return even there is no A7105 chip at all, but of course that will cause a infinite loop since there is watchdog reset function in the Flysky init loop (could we give it a retry limit? in which case the DEVO tx will not get stucked if A7105 chip failed). The most interesting part is that the compiler could possibly remove the for loop during code optimization, that explains why the same code may work in some revisions but not others.
Great work!

PhracturedBlue wrote: I did a bunch of experimentation. Unfortunately my devo8 rarely locks up with the Flysky/hubsan protocols, but I was able to get some decent testing in. As Coldfilre speculated, the problem seems to be that spi_read hangs forever. I believe this is because the SPI read is never started (and thus never finishes). The STM32 has a rather odd interface to reading in 3-wire mode. you need to hold the spi enabled for more than 1 SPI clock and less than 8. The 'for()' loop was supposed to do that, but it is getting optimized out, so we aren't holding the enable long enough to guarantee that a read works.

I have checked in tweaked code which follows the Refernece Manual with respect to transmit and receive. It seems to work well for me, but I'd like everyone with issues to try the latest code and report back. If you get reboots, please provide the elf and errors.txt file. These are really helpful in letting me see what is going on.

Additionally I may not have been waiting long enough for the transmit to complete before shutdown, so I properly checked that too.

Please Log in or Create an account to join the conversation.

Start
Prev
1
Next
End

Time to create page: 0.061 seconds

Re-enable mobile display