Skip to content
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.

Sign up for GitHub

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

Jump to bottom

what happen to the red button it do not work any more #755

Closed
shelllanes opened this issue May 15, 2017 · 51 comments
Closed

what happen to the red button it do not work any more #755

shelllanes opened this issue May 15, 2017 · 51 comments

Comments

@shelllanes
Copy link

why is the red button do not work any more for dif talk grop
@shelllanes
Copy link
Author

and the light all way stay on now

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@shelllanes
Copy link
Author

ok when u did hit the red button a white screen come put where you can goto a dif talk group now when you hit the red button it do not work the white screen what did you do in the software

@shelllanes
Copy link
Author

the kd4z when you did a glv it not there any more the red button where you can goto dif talk group

@KD4Z
Copy link
Collaborator

KD4Z commented May 16, 2017

@wolf, We are this issue seeing wide spread since yesterday's commit 76efddf. Red button no longer opens new menu, and sometimes leaves display in full white condition. Also, the Backlight will not turn off, no matter what settings/timings you choose. I've reproduced it on two different MD-380's Have a handful of others that use my VM reporting same.

@wolf
Copy link

wolf commented May 16, 2017

When you mention @wolf in your message instead of @Wolf-DL4YHF: I get email because I was mentioned. Please use the full @ name to ensure the right person gets the message.

@shelllanes
Copy link
Author

shelllanes commented May 16, 2017 via email

@shelllanes
Copy link
Author

shelllanes commented May 16, 2017 via email

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@KD4Z
Copy link
Collaborator

KD4Z commented May 16, 2017

Sorry @Wolf-DL4YHF , I had your ID selected but did't notice it didn't stay put. Shell Lanes is referring to this project. https://github.com/KD4Z/md380tools-vm It's a full on Debian distro, ready to go with added scripting to make running the tools menu driven and easy to deply for Windows/ macOS / or plain Linux platforms. It pulls from the master branch of Travis' md380tools. There are almost 1000 users making firmware updates to their radios using this VM. You might install it using the VirtualBox host on Windows/macOS or can just install the Bash scripting portion on Linux or Rpi-- it runs the same build sequence either way.

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@KD4Z
Copy link
Collaborator

KD4Z commented May 16, 2017 •
edited

@Wolf-DL4YHF Ouch, looks like the build failed most spectaculary. I haven't used the Linux version of Virtual Box...just to host a Linux VM :) You can actually just install the Bash scripts on a native linux box. Go back to my github page and get the extra PDF to explain the rather simple process to get it going. Beware, it expects to blow out your .bash_alias file (to install the command aliases) and it will rm -rf the md380tools folder under your home folder and clone it again...so make sure you don't have anything there you want to keep. .... I've posted a fresh build of the 76efddf binaries built in my VM here for you. Of course, these are build under Debian in the VM....https://drive.google.com/file/d/0Bwoi2MrlPb3vd1I2dkVhcVlhQms/view?usp=sharing

@shelllanes
Copy link
Author

i hope wolf and kd4z fix it asap please and thank you

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 16, 2017 via email

@nessenj
Copy link

nessenj commented May 16, 2017

FYI, not sure if it matters or not, but I am running the KD4Z VM and i did a flash upgrade of my MD380 today and the version I have on my tools is 2017-04-22

Are we supposed to be seeing the 2017-05-16 version after we run 'flash' ?

@KD4Z
Copy link
Collaborator

KD4Z commented May 16, 2017

@nessenj Not related, though certainly it is not working correctly. You must have had errors fly by during the compile. This is not related to this issue we are working on here. Please take this to the VM support group on Facebook here: https://www.facebook.com/groups/KD4ZToolkit/

@nessenj
Copy link

nessenj commented May 16, 2017

@KD4Z ok, thanks. I wasn't sure, but i thought i'd share the version.

@KD4Z
Copy link
Collaborator

KD4Z commented May 17, 2017

@Wolf-DL4YHF , Very bizarre results indeed. You can use ftp from the command prompt in the VM. I use it all the time to move files in and out.. Of course, you will need an FTP server to connect to. I use a NAS on my local network for this. You can use any FTP server you have write permissions on. Or install a simple one on a linux box or Windows box. I've poke around your site and can't find the firmware build you mentioned. Might need a breadcrumb trail to find it. 17 May is travel day for me, so out of touch a while.

@shelllanes
Copy link
Author

i hope you guys can fix it asap

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 17, 2017 via email

@Wolf-DL4YHF
Copy link
Collaborator

With a fresh cloned repository, compiled into the No-GPS-firmware (D13.020 base) on a 'fresh' 64-bit Debian 8.8 system (installed exactly as described in md380tools/README.md), I get the same, functional firmware as when building the same, fresh clone from the official travisgoodspeed repository under windows/MinGW.

Only when building it in the VM, I get the already mentioned problem with the non-functional 'red button menu'. I didn't manage to pull out the list- and map-files from the VM, but here is mine, compiled on a freshly installed Debian system, from the 'fresh clone':
http://www.qsl.net/dl4yhf/RT3/applet_NoGPS_compiled_on_Debian.map

Maybe you can compare the file (original name is just "applet.map") - especially the sizes and addresses of functions and variables MUST be equal, if we really use the same ARM compiler / linker toolchain:

If the map file of the compiled applet shows no significant differences, the next item to check is the complex Python-driven merge process in the VM.
Here is the complete dump from the Linux console when installing the MD380Tools (cloned today), and the entire output from the compile / link / merge / patch process, also for comparison:

http://www.qsl.net/dl4yhf/RT3/MD380Tools_console_output_from_Build_All_under_Debian_64bit_2017_05_17.txt

The first half shows the messages during installation (again, under Debian, on a german PC).
The second half shows the output from the compiler. I didn't manage to copy the entire output from the VM (since it's not a nice graphic console with thousands of lines to scroll-back, select text, and copy to the clipboard), but comparing the messages may give us a clue what's going wrong when compiling the recent firmware in the VM.

Since BOTH (the backlight dimming and the keyboard-polling for the 'red key menu') take place in the re-directed SysTick_Handler, I can imagine that the PATCHING process goes wrong.
You can see (and compare) that in the last few lines during the build process.
Especially the addresses shown next to "old value in vector table" (etc) are crucial.
If the SysTick_Handler (a kind of "timer interrupt") isn't properly patched, the experimental firmware will

  • you guess - not be able to dim the backlight, and poll the keyboard for the new menu. Hmm....

python2 merge_d13.020.py merged.img applet.img 0x0809b000
Merging an applet.
Loading symbols from applet.img.sym
Inserting a stub hook at 0800c72e to 0809cb31.
Patching SysTick_Handler in VT addr 0x0800c03c,
old value in vector table = 0x08093f1d, <<< ! important !
expected in vector table = 0x08093f1d, <<<
new value in vector table = 0x080a2a15. <<<
SysTick_Handler successfully patched.
Merging applet.img into merged.img at 0809b000
Merging applet.img into merged.img at 0809b000
../md380-fw --wrap merged.img wrapped.bin
DEBUG: reading "merged.img"
INFO: base address 0x800c000
INFO: length 0xf3000
DEBUG: writing "wrapped.bin"
cp wrapped.bin experiment.bin
make[1]: Leaving directory '/media/shared/md380tools/applet'
root@yhf:/media/shared/md380tools# python md380_dfu.py upgrade applet/experiment.bin
Beginning firmware upgrade. (...)

@Wolf-DL4YHF
Copy link
Collaborator

Hi Warren,
Is there a chance to log into the VM as root, to change the keyboard layout and to mount a new folder with a shared storage medium ? The US keyboard layout in the VM is driving me crazy, and I want to copy files from the VM's md380tools to a shared folder for further examination.
I now got an up-to-date firmware compilation date after "glv" + "flash", but -much in contrast to the 'large' Debian system where everything works as it should, the backlight + keyboard polling for the app-menu still doesn't work. Furthermore, the important messages disappear so quickly from the full-screen console that I cannot read them, and in the VM I cannot scroll them back (as in a graphic console window with a scroller and a text buffer).

So being able to log in as root (in your VM) would help a lot. I don't use Facebook (and never will) so I cannot check the VM forum for an answer.

The plan is to copy everything from your VM / md380tools into my Debian installation, where everything works (including backlight dimming + red-button-menu). So there must be a difference somewhere - but that's the big question.

@KD4Z
Copy link
Collaborator

KD4Z commented May 18, 2017 via email

@roelandjansen
Copy link
Contributor

roelandjansen commented May 18, 2017 •
edited

Warren,

what if I would build it under SUSE and check? There always is a possibility his toolchain is wrecked/broken or the git fetch/merge/pull/clone failed.

I build the code natively and after the push it's also available as an artefact on git too so he could flash that one as well.

Roeland

@roelandjansen
Copy link
Contributor

CI:Commencing build for f0d3d01
CI Published https://github.com/roelandjansen/md380tools/releases/tag/f0d3d01 as prerelease

he could test this one.

@roelandjansen
Copy link
Contributor

and yes, it's tested, morse works.

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 18, 2017 via email

@shelllanes
Copy link
Author

hey wolf the back light stay on all the time no matter what setting the back light on can u see what is wrong the user keep ask me how long is it going to take i say to them they are working on it you say that u put it in your radio right and the red button do not work when u can go to dif talk group plz help us thanks :)

@Forts117
Copy link

@shelllanes relax man :) As you can see they have been able to reproduce the issue and are ruling out lots of different things to determine the cause. It'll be fixed when it's fixed. These fine folks work on this in their free time and are not obligated in an way to provide us with a time when it'll be fixed. Users can roll back to older firmware for the time being or just sit tight until things are patched up... They'll survive!!

@Wolf-DL4YHF
Copy link
Collaborator

Indeed, please accept that I'm doing this in my limited spare time.
But in the meantime I have a version that also seems to work when compiled inside the KD4Z virtual machine. The binary result is still different (compared against firmware compiled on a 'big, fresh Debian' and on Windows, also 64-bit), but hopefully BOTH binaries (even though they are different!) will work.
A request for merging is already pending, and if it passes the test on the Travis CI server, I will merge it myself because this seems the only way to test the complete "workflow", using the glv command in KD4Z's VM . More on that later. I just see PR #758 has passed the test on the CI server, but that doesn't mean a lot - we need to test it on different radios.

Still the question remains : Why on earth does it make a difference if the SAME C SOURCES are compiled on different Linux systems, when they all use the same cross compiler / linker toolchain ?
Any expert out there who can look into this ? As already mentioned, it's easy to see the difference when comparing the map files (generated by the ARM linker, applet/applet.map).

@roelandjansen
Copy link
Contributor

same sources --> different compiler version, runtime libs. Even the compiler itself may be compiled on a different compiler compared to what you and I have I guess.

The best thing is to have a set of working tools as in "preferred" and if something fails... out of luck. Those things may take too much time to debug/find out.

I assume we would not want to have compilerchain specific fixes in the sources..

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 19, 2017 via email

@Wolf-DL4YHF Wolf-DL4YHF mentioned this issue May 19, 2017
Merged
@pjao
Copy link

pjao commented May 20, 2017

Hi @Wolf-DL4YHF and @KD4Z !

For what I've see, the problem could and should be changes made on "display.c".

On the preparation it calls md380tools-vm/exec.pre that makes the replace of the original "display.c" that is not proper changed with last updates.

So on my point of view, it's needed to fix the "display.c" of KD4Z VM, and only after that the problem should be fixed.

73's all
Paulo - CT2JAY

@KD4Z
Copy link
Collaborator

KD4Z commented May 20, 2017 via email

@pjao
Copy link

pjao commented May 20, 2017

Hey @KD4Z

I may have mispronounced when I said "proper." What I thought was that they did not reflect all the changes made in the last pull requests.

@pjao
Copy link

pjao commented May 20, 2017 •
edited

@KD4Z

I've made this quick change in display.c of your VM, reflecting some changes that was made on the last pulls.

I love your display, and always saying good job, don't miss understand me.

I've compiled it, and it's working with your green line, red key and morse.

Plz see the attch file.

display.zip

@pjao
Copy link

pjao commented May 20, 2017

@Wolf-DL4YHF,
Display.c was replaced with glv with a version that is 27 days old, and doesn't have the latest changes made on md380tools.
Getting most of that changes into display.c fix the problem.
I've also tried your way, different machines and OS, that gives different binaries, but the problem was always the same.
Good job!
Thanks to you also!

@berferd
Copy link

berferd commented May 20, 2017

@pjao

Please don't let the rude response of @KD4Z dissuade you. Thank you very much for volunteering your personal time to look at this issue. I trust an apology is forthcoming from @KD4Z.

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 20, 2017 via email

@Wolf-DL4YHF
Copy link
Collaborator

Indeed the kludge seems to work, the KD4Z VM compiles a firmware in which backlight + red-key-menu are available.
As explained in my previous post, SysTick_Handler now waits patiently for the hooked "draw_statusline" (in display.c) to be called, before it allows to open the new menu. Plus (and this is the kludge), if that did NOT happen within some seconds after power-on, it also declares itself "open for business".

Et voila, declaring ourselves "open for business" (which means our own LCD driver is allowed to take over control) after some seconds fixes it. This is done in addition to setting boot-flag "BOOT_FLAG_DREW_STATUSLINE" (nomen est omen) in the draw-statusline-hook,

Phew.

I will leave this issue open for now, because the kludge described above isn't a real fix.
The real fix would be getting an idential compiled / patched binary regardless on where we build it.
Simimar as someone wrote in one of the source codes, "this bug will come back to bite us" !

@pjao
Copy link

pjao commented May 20, 2017

Thanks @Wolf-DL4YHF!

I don't have the time to understand all the code, so for me, it was important to find the location of the problem, after that, your analysis and fix/workaround was one step.

People that fork projects, must keep all files updated, and of course include all changes, if they want to keep all the new updates in order and working.

@roelandjansen
Copy link
Contributor

well....

in fact if a fork is on a different branch, it should not be supported here when it comes to bugs if you ask me..

@DL2MF
Copy link
Collaborator

DL2MF commented May 20, 2017 •
edited

... the sources get more and more confusing by fixes for 3rd party tools like the latest fixes:

// .... but when compiled in the KD4Z VM, something was missing, // possibly an improperly hooked function (hook not called), so: if( IRQ_dwSysTickCounter > 6000 ) // <- very ugly kludge (2017-05-20) { boot_flags |= (BOOT_FLAG_INIT_BACKLIGHT | BOOT_FLAG_LOADED_CONFIG | BOOT_FLAG_DREW_STATUSLINE); // heavens, no ! }

If it's running with linux, it should not be fixed for other OS environments if not officially supported by this master-branch.

just my 2 cent ...

Also, several weeks ago I've been asked to remove my callsign from comment lines inside my sourcecode changes, today we found a lot of DL4YHF in many files (main.c, gfx.c, irq-handlers.h, menu.c ...)

@Wolf-DL4YHF
Copy link
Collaborator

Ok, I can remove my callsign from all modules that I didn't write myself. No problem with that.

But I will not remove them from the new files I contributed to the project. That especially applies to irq_handlers, lcd_driver, app_menu, the hex-monitor, etc. Really, I find it helpful to see in the sourcecode (!) who wrote a module, so I know whom to ask without without having to dig that out in Github.

@DL2MF
Copy link
Collaborator

DL2MF commented May 20, 2017 •
edited

I like comments in source code and also for some minor changes it might be helpful to see, who was the author of a modification (yes, we can get it also from github versions).

This was, what I received, when I added first support of some MD390 stuff and symbols before all the lastheard, netmon and TA stuff I have been working on later:

`@sijskes commented on this pull request.

In applet/src/gfx.c:

@@ -237,6 +237,10 @@ void gfx_drawbmp_hook( void *bmp, int x, int y )
return ;
}
gfx_drawbmp( bmp, x, y );
// redraw promiscuous mode eye icon overlapped by antenna icon on MD390/G 20161118 - DL2MF
if( ( global_addl_config.promtg ) && ( y == 0 )) {
`
stop putting date and callsign in patches. if everybody did that it becomes a mess.

@Wolf-DL4YHF
Copy link
Collaborator

Wolf-DL4YHF commented May 20, 2017 via email •
edited

Wolf-DL4YHF referenced this issue May 20, 2017
@Wolf-DL4YHF
kludge to get backlight and app-menu running in KD4Z VM
d746672 
SysTick_Handler declares itself "open for business"
even if draw-statusline-hook in display.c was NOT called,
when nothing happened for several seconds after power-on.
@Wolf-DL4YHF
Copy link
Collaborator

Suggest to close this issue - it's solved, at least from my point of view

@travisgoodspeed
Copy link
Owner

Done.

@shelllanes
Copy link
Author

shelllanes commented Jul 4, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests