md380tools icon indicating copy to clipboard operation
md380tools copied to clipboard

usb stability during md380tool {dmesgtail, spiflashdump} [SD]13.020

Open sijskes opened this issue 8 years ago • 19 comments

when pulling the 'side-plug' from the md380 during dmesgtail, there is a high prob of hanging the md380.

sijskes avatar Sep 14 '16 11:09 sijskes

Could you please elaborate a bit, what radio, firmware and PC did you experience this with? I have also experienced that the same applies to the other usb interfacing tools if you are too quick pulling the cable out. This was a MD390 GPS w S013.020 firmware and 64bit Ubuntu 16.04.

ghost avatar Sep 14 '16 11:09 ghost

md380. ubuntu install conform recipe. 64bits. 16.04. d13.020. high traffic dmesg printf local patch.

sijskes avatar Sep 14 '16 11:09 sijskes

Could be a complicated threading thing, but it might also be that dmesg_tx_buf is reused by a lot of different functions. We need to clean up the linking description to be able to conveniently place buffers in both SRAM and TCRAM.

(TCRAM at 0x10000000 cannot be used for DMA, but we have more if it than the SRAM at 0x20000000.)

travisgoodspeed avatar Sep 14 '16 11:09 travisgoodspeed

i have the impression that pulling the plug glitches the PTT. anybody confirming?

sijskes avatar Sep 14 '16 12:09 sijskes

Oh yeah, that'd do it. I've had some luck with a ferrite choke around the USB cable, but realistically, I don't think the hardware is stable enough to transmit with the default cable.

Close this issue if we can confirm it's not a software problem.

travisgoodspeed avatar Sep 14 '16 12:09 travisgoodspeed

also ./md380-tool spiflashdump makes problems -> no keypad response

aeickho avatar Sep 25 '16 09:09 aeickho

next try... remove all none usb hooks

aeickho avatar Sep 25 '16 09:09 aeickho

(remove all none usb hooks) same problem (no keypad response + no screen update (clock))

more delays between the usb transfers there are no changes

aeickho avatar Sep 25 '16 09:09 aeickho

perhaps there is a transfer errors from d02.32 to [DS]13.020 :(

there are so many variables

aeickho avatar Sep 25 '16 09:09 aeickho

@aeickho no, the dmesgtail on d13 works. but slows down gui, considerable.

sijskes avatar Sep 25 '16 10:09 sijskes

on my RT8 S13 woks flash whitout error or warning

Am 25.09.2016 um 12:06 schrieb Simon IJskes:

@aeickho https://github.com/aeickho no, the dmesgtail on d13 works. but slows down gui, considerable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/295#issuecomment-249413336, or mute the thread https://github.com/notifications/unsubscribe-auth/AVS3TQ5Ty2yVzV9tFb7DF9yac8GqE2rLks5qtke1gaJpZM4J8qw-.

ispkorte avatar Sep 25 '16 10:09 ispkorte

sijskes > @aeickho no, the dmesgtail on d13 works. but slows down gui, considerable. yes this is true

but ./md380-tool spiflashdump makes problems also with d13.020 ->menu->back (repeat 10 times) no keypad response + no screen update (clock)

on d13.020 not so intrusive @ s13.020

aeickho avatar Sep 25 '16 11:09 aeickho

Alex, as we speak I am dumping my md380 into a file and the time / menu works OK. This is under vmware workstation, vm is debian 8.x and the virtualization host is opensuse.

Could you tell me if we do the same thing?

roelandjansen avatar Sep 25 '16 11:09 roelandjansen

@roelandjansen i use a native linux system.

dump the 16Mbyte spi flash to the pc:

./md380-tool spiflashdump file.bin

my idea ... your system is not so fast ... (usb virtualization)

your radio? S or D Type?

aeickho avatar Sep 25 '16 11:09 aeickho

@sijskes > @aeickho no, the dmesgtail on d13 works. but slows down gui, considerable.

you can reduce the slowness of md380 while dmesgtail with add a sleep into md380-tool -> dmesgtail()

aeickho avatar Sep 25 '16 11:09 aeickho

e.g. you mean that if it's faster it would be come unstable. Ok.

How long does your dump take? I could see if I can natively dump it in the system too and see if that makes any difference in time.

roelandjansen avatar Sep 25 '16 11:09 roelandjansen

@roelandjansen

time ./md380-tool spiflashdump file.bin (no keys are pressed)

  • on s13.020 (gps) after 12 sec no time update .. real 1m47.499s .. can't switch power off
  • on d13.020 real 1m48.584s... radio is working (power of is working)

time ./md380-tool spiflashdump file.bin (->menu->back (repeats x times )

  • on s13.020 not tested
  • on d13.020 after ≉ 4 repeats of (->menu->back) - real 1m46.165s (dump is complied) - no time update .. can't switch power off
  • on d02.032 after ≉ 10 repeats of (->menu->back) - no menu action possible . watchdog -> reboot

aeickho avatar Sep 25 '16 11:09 aeickho

ok,

roeland@md380:~/src/d$ time ../md380tools/md380-tool spiflashdump dumped Dumping SPI Flash to 'dumped'.

real 1m53.467s user 0m7.420s sys 0m1.852s

radio stayed responsive. I did it just one time. I am backing up the vm at this moment and will try and see repeatedly if I also see this bevaviour. I did a single shot and that one worked OK.

roelandjansen avatar Sep 25 '16 11:09 roelandjansen

Self assigning to take care of this over the weekend. I'll spin up a few related issues to migrate the features that require fast polling away from dmesg.

travisgoodspeed avatar Oct 28 '16 12:10 travisgoodspeed