Tagged: koryuu firmware fw
December 22, 2020 at 12:33 AM #43899
@aotta I tried to find out if there might be something wrong with -ntp (No Test Pattern) firmware, but couldn’t find anything that would explain the test pattern being displayed when there is no input. Could you try and describe me the scenario(s) where the test pattern ends up being displayed despite the -ntp firmware being used, please?December 22, 2020 at 9:53 AM #43905
@megari: i flashed the -ntp firmware on Koryuu and i got test pattern in output composite when no cable it’s connected in input ports. Just tested your RC1-ntp too, same result. I reflashed the default version, and made some “verify” to be sure the fw in the AVR is loaded fine, but found no error in flashing memory. I didn’t found the version 1.0 to make further test, is there some others check i can do?
after more test, playing with code of your main.cpp, i rid off of the test patter only removing the write in 0x82 and 0x84 subaddress, where you put the #if 0 conditional compiling: in this way, i got no test pattern (and, no computer output too, but i expected this), but…. the OSSC find in any case an output signal and its auto tune set the input to Koryuu!
Wasn’t that the scope of the NTP version? i think i’ll remain to the “default” branch and poweroff the koryuu when not in use.. it’s simpler and more “green” 😉December 23, 2020 at 7:03 PM #43944
Could you try the 1.1-RC2 NTP version? I reworked the NTP code a bit to try and eliminate corner cases. Now the encoder chip is also explicitly set to sleep mode with all DACs disabled when in free-run mode and in NTP mode.
The writes to subaddresses 0x82 and 0x84 are unrelated to NTP mode.December 23, 2020 at 9:42 PM #43948
Hi @megari, you got it! RC2 works fine with both composite and s-video (no) input!
The only (very) minor issue is that, i think, the null input is checked only at startup, so if power on the input after some time, Koryuu continue to sleep.
But i’m very happy to have the NTP working, and interested in looking at changes you made to code!
Thank you!December 24, 2020 at 1:12 AM #43954
@aotta Thank you for testing. It does concern me that the Koryuu fails to wake up from sleep after an input is connected. Does cycling through the different inputs (using the Input Change button) make it wake up eventually?
I’ll try and get some further improvements done.December 24, 2020 at 10:26 AM #43960
@megari Tested and confirming that cycling inputs wake up video correctly. But i think the original scope of the user asking for the NTP feature was leave Koryuu always powerd and hidden behind the TV/Monitor, so a different approach will be useful (although i think too it’s not so safe for Koryuu’s lifetime).December 25, 2020 at 5:27 PM #43990
@əotta I pushed a new tag today (fw_1.1-RC3). Could you try it out for me, please? I would like to make sure that the Koryuu does not fail to automatically wake up from sleep if the currently selected input (in an inactive state) becomes active and starts producing a video signal.December 25, 2020 at 6:44 PM #43993
hi @megari and Merry XMas!
i just flashed your RC3 bud didn’t found differences from the previous RC2 one: if no input at Koryuu starting, it wake up only with a power cycle or at change input setting’s cycle.
If Koryuu find input signal at startup, it works normally, but show test pattern when input source is powered off.
I dont’ know if it’s the expected behaviour. Tested with both s-video and composite input.December 25, 2020 at 11:08 PM #44000
So, with the NTP version of firmware version 1.1-RC3, you are observing the following behavior:
- Initial state: Koryuu is off, all video sources connected to Koryuu inputs are off.
- Koryuu is turned on. The color bars test pattern is not shown. The device connected to the Koryuu (such as the OSSC) indicates no video signal is being produced by the Koryuu.
- The Koryuu input setting is set appropriately.
- Some time passes (how long?).
- The video source connected to the Koryuu input selected above is turned on.
- The Koryuu continues not to produce a video signal, as indicated by the device connected to the Koryuu (such as the OSSC).
- After cycling through the input choices on the Koryuu all the way back to the input selected above, Koryuu starts producing a video signal, as indicated by the device connected to the Koryuu (such as the OSSC).
Also, if the input source is active on Koryuu startup, the picture comes up OK, and after the video source is turned off, the color bars test pattern is shown by the Koryuu.
If the above is accurate in its description of what you are seeing, I am stumped. I cannot see how the behavior above is possible, judging from the firmware source code. Are you absolutely sure that you are flashing the correct version (1.1-RC3) and variant (-ntp) of the firmware on the Koryuu? Are you using the pre-built .hex images in the .zip files in the releases/ directory or are you building them yourself from the source code?December 25, 2020 at 11:32 PM #44001
@megari, i flashed the hex in your release RC3 zip files. I did it again, after noticed no difference from the RC2 FW.
And what i get it’s exactly how you listed. About time in 4), i waited same seconds and few minutes, but no changed.
You know my board has some hw issue since arrival, and my replacing the ATMEGA may be added some other oddities to my Koryuu… i think you should’t take my test in care, if i’m the only user that has this result.December 31, 2020 at 7:35 AM #44108newsupermarkioParticipant
Hi @megari, I tried out the 1.1-test1.zip FW. This version seems more stable, but after a while, I still do see the issues as noted previously with 1-1-test0 and the other experimental versions (https://videogameperfection.com/forums/topic/new-koryuu-test-firmware-1-1-test0/#post-42737).March 24, 2021 at 10:23 AM #46125LeToParticipant
I have try to update the Koryuu with an Atmel Avr ISP MKII but I failed 🙁 (AVRDUDESS didn’t see the controller inside the Koryuu )
Perhaps a voltage problem with the jumpers at the down left part of the programmer?
May I used Microschip studio software (Programming tool module) instead ? It’s seams to see the correct controller inside the Koryuu but I’m afraid to lost the internal firmware in case of failure so I prefer to ask you before I try. Can I try directly without any modification of the PCB/connectors or should I made something before ?
Thanks a lot.
RegardsMarch 25, 2021 at 4:03 AM #46145March 25, 2021 at 12:40 PM #46158LeToParticipant
Hello, Ok thanks but I don’t have exactly the same model of programmer.
I have this one:
I have opened it and I only have two choices : 3V or 5V (no Target OFF jumper)
I have try both but AVRDUDESS didn’t see in any case the controller.
When I tried with Microschip studio software, the soft see the controller of the Koryuu. So, it seems to be OK but I’m not sure that the software is totally compatible with this kind of firmware and I’m afraid to delete the internal firmware without to possibility to update it finally.
Best regardsMarch 25, 2021 at 9:32 PM #46169
Hmm. That programmer resembles the one from Seeedstudio: Atmel AVRISP STK500 USB ISP Programmer, which is also being sold by Digikey. According to the PDF manual available on Digikey, the programmer type should be set to STK500. This may or may not have an effect.
What drivers are you using for the programmer? Have you tried the libusb32 or libusb-K driver (using Zadig)?
The voltage should be set to 5V. Having target mode off is mainly to protect the programmer itself from burning out from interaction with the PSU. If there is no jumper for it, you can check if the 5V pin outputs any power (you try lighting up an LED through a resistor with it, for example).
Using Atmel/Microchip Studio should be fine, but you may want to try reading the old firmware off the Koryuu just to see that the programmer works reliably. If that works without any errors, flashing a new firmware image should as well. As long as you do not change any fuse settings, bricking the MCU is very unlikely.
- You must be logged in to reply to this topic.