2.9.64 and 2.9.65 doesn't work #1610
Comments
|
Hi, Thanks! |
|
2.9.65 loaded but when ran the new firmware all I got on the screen was the upper right portion of a normal screen. Nothing worked. So I tried to reload 2.9.64 which worked before I loaded 2.9.65. Now when loading the 64 version I got an error 2 message at the bottom of the screen and it wouldn't run. I am now at firmware version 2.9.63 and it works. WM9I |
|
"Error 2" I have seen some months ago when bootloader was not able to access USB stick. In my case it was a damaged stick. But it is so long ago that I cannot remember what was exactly the text message and where it was placed... Could you please test using another USB stick? |
|
Replace the USB stick and loaded 2.9.65 firmware. I got the same results but with No Error 2 message. When I tried to run the new firmware I get just the upper right hand one 4th of a normal screen. 2.9.64 firmware loads OK now. WM0I |
|
Hi, |
|
Boot screen seams to be working but the main screen is not. The best I can describe what I see is if you cut the main screen up into 4 sections 2 x 2 . Nothing works and I have to take power off to turn it off. |
|
Ok, yes, description makes enough sense to me. You have a STM32F4 with 512k if I remember correctly. Is that right? Parallel or Serial display, see System Info menu, in case you don't know this. |
|
What I am seeing in system info is HY28B SP1 and 512k. So I guess I need a newer UI board which is no longer available. |
|
Hi, |
|
I do have a mcHF with SPI-display and it works like a charm with 2.9.65 firmware. It uses STM32F429 MCU... |
|
My CPU is 413h. WM0I |
|
Hi Rich, your MCU is F40x@512KB - the smallest one which is available / will work on mcHF. The number alone is not sufficient for description - the amount of flash must be added. Noone here has access to this MCU. |
|
Hi, |
Attempt to fix #1610: Delay reaction to external interrupts until full init
|
Sorry - accidently closed. |
|
I am exited if 2.9.66 has different behaviour at affected radio... |
|
2.9.64 working normal, but 2.9.65 and 2.9.66 not (512 kB) |
|
Same problem with 2.9.65 and 2.9.66 |
|
Hi @UR7FM |
|
I have disabled it. If this makes a difference we must investigate what is going on. Release 67 will be published in a few seconds |
|
This was my idea too: the problem is sleeping at an unidentified part. Unhappily I am nearly sure we will not find it until we do have access to a machine which shows the issue. I never have had seen such a machine. |
|
Question to all: Does anyone have a MCU > 512KB flash which shows the issue? |
|
And again: all of my ideas are trapped in "impossible because it does not impact all machines with F40x processor". All do have same amount of RAM, SRAM, same registers - everything identical - only the amount of flash differs and that cannot be the reason for crashing (I do not see what mech can cause this). Possibly we have found a hardware issue in some revisions of F4 MCUs @512Kb. Of course it can be approached by peeking and poking in the existing code (bisect...) but having direct acess to such a device will make it much, much easier. And if the reason is not trivial (and I am thinking it is not trivial) time to fix it will be long enough if we can access device. Maybe it is not fixable because we can detemine the part of code but not explain what is happening. |
|
Yes, that it is not happening on all devices is what puzzles me most. |
|
You have done great work Danilo. It is very wise and I am glad that your decision is like this. Could you pse mak a PR for the feature "showing CPU revision in System Menu"? @ALL who are impacted by this issue: many thanks for your help. We have done big steps forward but now we need more than testing... Until we have done that you can test new binaries of course. They may - or may not - work for you. Last time we have had the isue it was enough to move the position of an independent working function to another place - rediculuous and without any explanation - but it was solving the issue for the 512KB machines. By chance... |
|
Unfortunately, even the 2.9.69 has the same behaviour in my Chinese clone RS-918 - which, to my knowledge, is identical to the mchf. Only the upper right part of the screen is visible as I mentioned in a previous post of mine. Access to an impacted device seems to be the only solution to the problem. Thank you so much for your efforts guys! |
|
We need a radio which shows the issue. No other way. None of our radios does have any issue, and it seems that nobody in our German discussion group does have the issue, too. EDIT: |
|
df8oe, again if I sent you my rig/unite to you I would not have anything to use on HF. How do you propose we handle the transfer to you? How long would have to have it? Is their away to trade my rig/unite for the next level up? How much? I want to help but I don't want to be without of a radio either. Best regards |
|
Hi Guys, |
|
Super MSG, thank you |
|
Hi Guys,
And we will have a solution soon! |
|
This sounds like a trailer for new movie :) |
|
Hi Danilo, |
|
It is a game against the clock. Literally! |
The bootloader's interrupt handlers manipulated the data segment memory since this is initialized before the new vector table is set and the new interrupts get activated. Solution: We the bootloader starts the firmware through a shared variable (which we used already, but not for normal start) and after reset it goes straight to firmware without enabling any interrupt. Safest way to do it.
|
The end is near, do not fear! |
The bootloader's interrupt handlers manipulated the data segment memory since this is initialized before the new vector table is set and the new interrupts get activated. Solution: We the bootloader starts the firmware through a shared variable (which we used already, but not for normal start) and after reset it goes straight to firmware without enabling any interrupt. Safest way to do it.
|
While we are all waiting for Travis to do its job, here is the thing: Solution is straightforward: We disable all interrupts before starting the firmware. We do this in a safe way, we simply reset the processor and then go straight to the firmware, the process basically goes straight from reset to firmware. We do this by checking for a magic number in a special memory location, if it is there, we know we should start the firmware rightaway, otherwise we run through the normal bootloader code. |
|
it sounds like dejavu for me... I had similar problem few months ago in F103 project... The total calm down for core before exiting the bootloader and changing the VTOR is a must. Anyway, good job, congratulations! |
|
Good job! |
|
What an amazing story! The only 512kB chinese clone, i ever had on my bench, was löng ago back to the owner, so I can't help you . But anyway, you solved the problen, Danilo! What should we do without you? |
Fixed issue #1610: Firmware not working.
|
Congratulation - good job Milan |
|
FANTASTIC, Works great. I am going to do some test to see if other small issues have cleared up with this new bootloader. Great work. Best regards |
|
Hi Rich, can you power on with normal press on power button or must you press button for 2 seconds? |
|
Great ! And another thing. My m0nka mchf number two have a 1024 flash. Yesterday I saw the same problem on that one to !! You are the best ! |
|
It looks normal except for the double white screen flash. I do have to hold it down until the RED transmit led comes on. But that seams to be normal. But overall it works. |
|
I think we can close this issue now. Please note: We will not support anyone with older bootloaders and strange issues! Confirm that the issue exists with 5.0.1 or newer and only then do a report on it. 73 |
both updates do not load, I had to go back to 2.9.63
WM0I
The text was updated successfully, but these errors were encountered: