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

[shelllanes]

why is the red button do not work any more for dif talk grop

[shelllanes]

and the light all way stay on now

[Wolf-DL4YHF]

Can you explain a bit more what you did, step by step, and what doesn't work ? No reaction when pressing the red button on the main screen at all ? Not able to navigate to menu item "TkGrp" ? Not able to edit / input a new talkgroup there ?

Needless to say, on my own radio (an RT-3 with D13.020 based firmware) everything works as it should: Press red button on main screen. The new menu opens. Press cursor down until "TkGrp" is highlighted. Press green key (I call it the "Enter" key because that's what it usually does). Type in a new talkgroup. Press Enter again. New talkgroup is active, at least as far I can see in DMR simplex.

Cheers, Wolf .

Am 16.05.2017 um 00:41 schrieb shelllanes:

why is the red button do not work any more for dif talk grop

— 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/755, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfZKQUoXjPR2EH_aXdk-02W5sX6Hrks5r6NSZgaJpZM4NbyNV.

[shelllanes]

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]

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

[KD4Z]

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

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]

can you fix kd4z software or can you fix the red button

On Tuesday, May 16, 2017 2:58 PM, KD4Z <notifications@github.com> wrote:

@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.— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[shelllanes]

he used virual box to run on windows

On Tuesday, May 16, 2017 12:28 PM, Wolf-DL4YHF <notifications@github.com> wrote:

Can you explain a bit more what you did, step by step, and what doesn't work ? No reaction when pressing the red button on the main screen at all ? Not able to navigate to menu item "TkGrp" ? Not able to edit / input a new talkgroup there ?

Needless to say, on my own radio (an RT-3 with D13.020 based firmware) everything works as it should: Press red button on main screen. The new menu opens. Press cursor down until "TkGrp" is highlighted. Press green key (I call it the "Enter" key because that's what it usually does). Type in a new talkgroup. Press Enter again. New talkgroup is active, at least as far I can see in DMR simplex.

Cheers, Wolf .

Am 16.05.2017 um 00:41 schrieb shelllanes:

why is the red button do not work any more for dif talk grop

— 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/755, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfZKQUoXjPR2EH_aXdk-02W5sX6Hrks5r6NSZgaJpZM4NbyNV.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Wolf-DL4YHF]

Ok thanks for clarifying. I wonder if this is related with the build environment or with the increased stack usage in the display driver (seems to me the most likely reason). I will try to compare the binary compiled under Windows with the one compiled under Linux/VM. More later, 73, Wolf (DL4YHF) .

Am 16.05.2017 um 20:58 schrieb KD4Z:

@wolf https://github.com/wolf, We are this issue seeing wide spread since yesterday's commit 76efddf https://github.com/travisgoodspeed/md380tools/commit/76efddf07ee1daf79e3d616cb31c7bcace0e1d76. 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.

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

[KD4Z]

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]

Yes understood. I'm already downloading the VM to see if it makes a difference on my radio, but the ~~900 MByte will take ages here. Is there a readily compiled binary (from your VM) available on a website, to compare with the *.bin built here using Windows / MinGW ? It should not make a difference since both use the same compiler / linker / makefile / etc, but you never know.. I tried Virtual Box some time ago but it was horrible - despite having installed the guest plugins (under Ubuntu) it couldn't access files on the host system, it couldn't access a USB 3.0 mass storage, so I ditched it again. Hope to get your VM running with more success .. keeping fingers crossed.

Cheers, Wolf .

Am 16.05.2017 um 22:19 schrieb KD4Z:

Sorry @Wolf-DL4YHF https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-301903027, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfacVsu6lDuDMHxVyhewJNc1fRq3Wks5r6gS_gaJpZM4NbyNV.

[Wolf-DL4YHF]

Hi Warren, I followed the step-by-step guide in German language by OE7BSH, also ran "glv" successfully, but... After updating the firmware in my RT3 I am now greeted by a firmware compiled 2017-01-03 . At the end of an endless stream of messages on the console, it says something like "cp: cannot stat (?) ... firmware-2017-05-16-NoGPS.bin : No such file or directory. Internet for the VM works, but it's very slow (same as my normal internet connection). Running the "flash" command was ok once (for the first time). Running "flash" a second time (to try on another radio) ends with "[Errno 32] Pipe error" - whatever that means. I haven't managed to scroll back in the megatons of console output to see the output from the C compiler or linker yet.

Off for today, 73, Wolf .

Am 16.05.2017 um 22:19 schrieb KD4Z:

Sorry @Wolf-DL4YHF https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-301903027, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfacVsu6lDuDMHxVyhewJNc1fRq3Wks5r6gS_gaJpZM4NbyNV.

[KD4Z]

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

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

[Wolf-DL4YHF]

This is bizarre - I downloaded the sourcecodes from github/travisgoodspeed/md380tools, did a file-diff (no difference except for the automagically modified line endings, which are magically converted from Windows to Unix format somewhere). Then I compiled it with my favourite building environment (MinGW, just because I'm more familiar with it than Linux) - all ok, red menu works, backlight dimming works as it should.

Then, in the VM, cd-ed into md380tools, issued command make clean image_D13 followed by python md380_dfu.py upgrade applet/experiment.bin

These are exactly the same commands as I use in MinGW (to build only the non-GPS firmware without wasting time). Both build without errors, download without errors, from both I am greeted with compilation date 2017-05-16 in the radio's power-up screen, and... tadaa.. in the firmware compiled with the VM, the backlight indeed doesn't dim, and the red menu button doesn't work. I'm puzzled. Tomorrow I will try to move files from my master directory (host file system) into the VM's guest file system (after finding out how), one by one, to find out where the difference is. So it's not a bug in the firmware, and it doesn't seem to be an outdated file in the VM (md380tools subdirectory), but somewhere between the sources and the final result something strange is happening.

Am 16.05.2017 um 23:44 schrieb KD4Z:

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 https://github.com/travisgoodspeed/md380tools/commit/76efddf07ee1daf79e3d616cb31c7bcace0e1d76 binaries here for you. https://drive.google.com/file/d/0Bwoi2MrlPb3vd1I2dkVhcVlhQms/view?usp=sharing

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-301924730, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfakXUaZsIl2k65mvhykslqV3Xi1Aks5r6hi0gaJpZM4NbyNV.

[Wolf-DL4YHF]

you could try the compiled binary from my website, I'm almost certain it will work. But copying this into the VM to the right place (before issuing the "flash" command) may be tricky...

Am 17.05.2017 um 00:20 schrieb shelllanes:

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-301932310, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfSoyLeGtARREsrmWGGv6vlxmtcGNks5r6iE3gaJpZM4NbyNV.

[nessenj]

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]

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

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

[KD4Z]

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

i hope you guys can fix it asap

[Wolf-DL4YHF]

Thanks - I will try my DSL/WLAN router as NAS to move the files around later. Or give the shared folder another try, but so far this is driving me crazy (similar as typing command lines with underscores and slashes in the VM on a german keyboard - I used a search engine to find where those keys are on a US keyboard).

About the breadcrumb: The zipped archive with the compiled non-GPS firmware is at

http://www.qsl.net/dl4yhf/RT3/dl4yhf_md380_firmware_experiment.zip

Firmware_NoGPS.bin is always the latest snapshot compiled with MinGW from the local repository. The sources are also included (applet folder), but not much else.

If it helps for forensic analysis: The cross compiler (arm-none-eabi-gcc) identifies itself as gcc version 5.4.1 20160919 (release)

Am 17.05.2017 um 02:16 schrieb KD4Z:

@Wolf-DL4YHF https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-301949819, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfQFcNfMw-IHneozYiT5mbrmfT57Gks5r6jxQgaJpZM4NbyNV.

[Wolf-DL4YHF]

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]

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]

The root user credential is the same as.the user that the VM auto logs on as.. tyt...

What bothers me is why did it stop working? The first merge last Sunday, where you pulled in the Red Menu worked just fine. Then , the next merge on Tuesday, it broke. Nothing changed in my code line in that period.

Warren

On May 18, 2017 2:37 PM, "Wolf-DL4YHF" notifications@github.com wrote:

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.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302504820, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ9urQ9hUI4kuRwabi821Dk4EAa7NyG_ks5r7I_0gaJpZM4NbyNV .

[roelandjansen]

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]

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

he could test this one.

[roelandjansen]

and yes, it's tested, morse works.

[Wolf-DL4YHF]

I suspect that, too. In the meantime I have successfully installed the virtual box 'guest additions' in the KD4Z VM, and can compare the intermediate files with a nice graphic file diffing tool. The map file (applet.map) looks extremely different, even though both were compiled on Debian (but one is 32-bit, and the one I use is 64-bit).

One of the strange things is that the ARM cross-compilation toolchain displays addresses (in the map file for the experimental firmware) with 16 digits when the linker was running on 64-bit Debian, and with 8 digits when the linker was running on 32-bit Debian. IMO it should be completely irrelevant on which kind of host system the cross-compilation toolchain is running (because the target system is what matters, and in our cases it's a 32-bit Cortex-ARM CPU). Indeed the addresses of almost anything in RAM and ROM is different. This shouldn't matter under ideal conditions, but in our case there may be subtle things (maybe some interrupt handler compiled on system A is a few microseconds faster than when compiled on system B).

Summary: For some reason, the toolchains produce different outputs. Plus, there's possibly a runtime / speed issue somewhere in the latest firmware development step. I will check this later, but we really should arrive at the same binary code running in the radio, regardless of how / on which platform we compiled it. If, depending on who compiles the firmware, and how, we get different results (xyz.bin), fixing bugs in the firmware (C sources) will be unnecessarily tough. And it's already "tough enough", believe me.

Am 18.05.2017 um 22:02 schrieb Roeland Jansen:

Warren,

what if I would build it under SUSE and check? There always is a possibility the toolchain is wrecked. I build natively and after the push it's also available as an artefact on git too so he could flash that one as well.

Roeland

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302525067, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfa3cOBUEZicDIM-0zs9zKfTbDn7-ks5r7KPWgaJpZM4NbyNV.

[shelllanes]

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]

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

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]

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]

Yes, I completely agree. But the bizarre truth is that the toolchain installed in the KD4Z VM is capable to compile a functional firmware, in which everything (including the dimmed backlight and the red-button-menu) works properly.

But I'm not enough of a Linux freak to tell why, and how exactly I got there (it involved brainlessly copying files from my own harddisk, taken from the freshly downloaded travisgoodspeed/md380tools repo) ! Basically, I created a fresh, empty 'md380tools' folder in a shared folder (accessable from within the virtual machine). Then I copied everything into that file. Next, to make sure the firmware was really compiled (completely) by the toolchain in the VM, I let a stoneage batchfile (!) kill everything that the compiler + linker are supposed to generate.

This involves (I probably forgot a few files here): rm applet/.o rm applet/.lst (not really necessary but for my own peace of mind) rm applet/lib/.o rm applet/lib/.lst rm *.pyc rm applet/experiment.bin , wrapped.bin, applet.elf, applet.img, merged.img, merged.map (again, for completeness)

Then, with the current working directory set to /media/shared/...blabla.../md380tools, and being logged in as root (not sure if that matters, but I needed "su" to create the shared folder anyway):

make clean image_D13

 followed by

python md380_dfu.py upgrade applet/experiment.bin

and I got a fully functioning radio with the firmware compiled, and patched, with the ARM compiler toolchain in the KD4Z VM !

The mystery remains, what's the difference when "glv" pulls the repository and invokes the compile / link / patch / merge toolchain ? Some outdated files not overwritten ? I can't say, and I stop now. It already took too much time, just as you said.

Am 19.05.2017 um 23:07 schrieb Roeland Jansen:

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302811513, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfVtiQ8CtfdMQdNhlkSgDcvpZ8p5Jks5r7gSPgaJpZM4NbyNV.

[pjao]

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]

Not your call Paulo. Proper ? You can go back to using main line code if you want "proper". Display has nothing to do with the missing red button action.

On May 19, 2017 8:26 PM, "Paulo - CT2JAY" notifications@github.com wrote:

Hi @Wolf-DL4YHF https://github.com/wolf-dl4yhf and @KD4Z https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302838117, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ9urRe6eevyyxwkisPPR9kZUXWgd1Z-ks5r7jNLgaJpZM4NbyNV .

[pjao]

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]

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

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

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

Hi Paulo, Warren, and all,

Many thanks for looking into this. Indeed a missing call of a hooked function makes the timer interrupt handler "think" that the display hasn't been initialized yet. And as long as the original firmware hasn't initialized the display, the new menu must not interfere. In my very first version, the timer interrupt (in SysTick_Handler) simply assumed that after a certain number of timer interrupts, the display would be "ready to use", and Tytera's tasks and interrupts would not interfere.

If that's the reason (in display.c), it should be easy to fix. I will simply let the SysTick_Handler declare itself "open for business" if either the status-line-drawing-hook was called, OR if more than some thousand timer interrupts were counted.

Sounds like a kludge and certainly is, but worth trying... more later.

73, Wolf DL4YHF .

Am 20.05.2017 um 02:26 schrieb Paulo - CT2JAY:

Hi @Wolf-DL4YHF https://github.com/wolf-dl4yhf and @KD4Z https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302838117, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfZ64e4RB9uFRNkr1JBjHlrZAF3Lqks5r7jNLgaJpZM4NbyNV.

[Wolf-DL4YHF]

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]

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]

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]

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

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]

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]

Thanks, that's a valid point. But if carefully used, dates in comments help to understand later why something not-so-obvious was done in a certain way. Along with the author's signature (or callsign, before I removed mine in the last 5 minutes), they also help to find out when those comments are not required because they are outdated. A recent example was the initial subject of this issue, a suspected bug in my recent modification in irq_handlers.c, that turned to be an outdated file in a virtual machine. Now, I'm going to remove the comments added between 2017-05-17 and 2017-05-20 again, they are easy to identify by their date (in glorious ISO-format, grep for 2017-05 .. done).

---Closing--- (edit: "Let's close") this issue because I'm beginning to hijack the topic.

73, Wolf DL4YHF .

Am 20.05.2017 um 23:09 schrieb Mike:

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, before I added all the lastheard, netmon and TA stuff:

`@sijskes https://github.com/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.`

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/755#issuecomment-302899004, or mute the thread https://github.com/notifications/unsubscribe-auth/AXwwfQ-a2AkgBO-nTRB87kLZOz98HxEEks5r71aNgaJpZM4NbyNV.

[Wolf-DL4YHF]

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

[travisgoodspeed]

Done.