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

[sijskes]

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

[ghost]

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.

[sijskes]

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

[travisgoodspeed]

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

[sijskes]

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

[travisgoodspeed]

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.

[aeickho]

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

[aeickho]

next try... remove all none usb hooks

[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]

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

there are so many variables

[sijskes]

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

[ispkorte]

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
#295 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVS3TQ5Ty2yVzV9tFb7DF9yac8GqE2rLks5qtke1gaJpZM4J8qw-.

[aeickho]

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

[roelandjansen]

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?

[aeickho]

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

@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()

[roelandjansen]

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.

[aeickho]

@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

[roelandjansen]

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.

[travisgoodspeed]

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.