Ideas or theory on odd problem related to spin program startup
Joms
Posts: 279
I have been fighting this problem for awhile and wondering if anyone has ideas. I figure before we get in depth in code, I am just wondering if anyone has ever seen something like this, or even if a code problem could cause this.
I have a project that outputs four different channels of video, but when I load the program the first time, it randomly does not work (only 1 or 2 channels will work). However, if I reboot the prop, or re-load the ram, it works every time.
Things I have tried and the result:
F11 (load eeprom) = does not work the first time, have to do it twice, or a F10 (load ram) after the eeprom.
F10 (load ram) = have to do this twice in a row to make it function
Power cycle = have to cycle power 2-3 times in a row (loading off eeprom)
Now this is doing this on 20 different prop setups, including the demo board. This is not inflated, I actually have 20 boards made up.
The only work around I have figured out, and it works, however very lame... I happen to have a RTC (real time clock) IC on this project. Every time the program loads it will check to see if the prop has just booted, or is on a reboot, then will write the current time/date to a spot in the EEPROM. This basically will boot the prop, then reboot it one time, so the program will load correctly...
Before we get too in depth in code, I don't see how this can be a code problem, however the prop demo board does not do this with other programs loaded for testing. Does it matter that I am using about 7/8 of the RAM when I do a F8? Ideas on what direction I should even start looking?
THANKS EVERYONE!
I have a project that outputs four different channels of video, but when I load the program the first time, it randomly does not work (only 1 or 2 channels will work). However, if I reboot the prop, or re-load the ram, it works every time.
Things I have tried and the result:
F11 (load eeprom) = does not work the first time, have to do it twice, or a F10 (load ram) after the eeprom.
F10 (load ram) = have to do this twice in a row to make it function
Power cycle = have to cycle power 2-3 times in a row (loading off eeprom)
Now this is doing this on 20 different prop setups, including the demo board. This is not inflated, I actually have 20 boards made up.
The only work around I have figured out, and it works, however very lame... I happen to have a RTC (real time clock) IC on this project. Every time the program loads it will check to see if the prop has just booted, or is on a reboot, then will write the current time/date to a spot in the EEPROM. This basically will boot the prop, then reboot it one time, so the program will load correctly...
Before we get too in depth in code, I don't see how this can be a code problem, however the prop demo board does not do this with other programs loaded for testing. Does it matter that I am using about 7/8 of the RAM when I do a F8? Ideas on what direction I should even start looking?
THANKS EVERYONE!
Comments
I had a similar problem with a propeller video overlay board. I found that the program would eventually run after the about a minute (I assume when the cnt overflows).
The only way I could fix it was to replace the propeller chip. I had about 10% that would do this. I never found out what the problem was....
Bean
Out of curiosity, under what conditions does a video channel not start up?
Kuroneko - Doing more playing with it, the power cycle like I first talked about is probably not an great test. Because the circuit is small, I am actually powering it off the USB port from the computer. This being said, I don't think there is a problem getting the power, but it is very likely that after I plug it in, when the usb-comm port is loading, the computer sends a reset command to the prop, thus like loading the eeprom a second time... There really isn't any condition that will prevent the video from starting, however after a minute or so it will start, just like what Bean ran into with his project.
That being said, is there any way I can reset the counter? Say I can have a wait for one second when the prop powers up, then resets the count. Does that sound like something that can be done, or is it more complicated then that? Bean - When you wrote your code for the video overlay, was there something specific to the cnt function that may be common to this that I can look for?
Thanks for your help guys, you got my gears turning. I actually never would have guessed to look in this direction, but it makes a ton of sense!
Nope, this one keeps going until you power down. Anyway, keep us informed about what you find. Or leave us some more clues we can chew on.
Are the video COGs started directly after each other? Maybe it helps to have short delays between starting the differend drivers.
Do the video outputs show different screens or do you have one frame-buffer for all?
Is HUB access somehow related to the CNT? If kuroneko is right and the CNT is not restarted and if the HUB access is related to the CNT maybe there is simply an order of HUB access which is fine and an order of HUB access which causes the problems.
So I'd check the video drivers for using the same DAT variable and move it to a VAR section?!
Interesting problem ;o)
Is your code secret? If it's reproducable on so many boards it would be easier to investigate on our own boards.
I tried everything. I put delays at startup (not using cnt), but it didn't help either.
I do recall so kind of issue with waitvid if you didn't set it up right, but that is just a guess. And I don't know why only certain chips did it.
I hope someone can figure out why this happens. I drove me nuts for months. And I wasted a bunch of propeller chips.
The pcb file is expresspcb. You can use these files anyway you want. If you want to make your own HC-OSD...Go for it.
Bean
That's not quite true. Further tests suggest that it starts from whatever is in the counter FFs at power-on.
@Bean: Thanks for the files.
Bean - I spent about an hour this morning re-building a circuit and then testing it that works with your code, mainly because it is something that most of us here have played with and your documentation really helps. I am playing with it on a bread-board using a DIP prop. The nice thing is I have about 8 props here I can switch between. Out of my pile, I am getting very mixed results.... It seems as if some of them do it, and some dont, just like you were discribing. Of the ones that do it, some do it more often then the others...
kuroneko - I have my prop book here looking at the cnt part. Is that where you found the documentation on the FFs? Bean might be able to help discribe this part, but wouldn't that cause this then if we are expecting the cnt to start at 0 or 1 when we start the prop? Maybe the video overlay doesn't start working until it sees the 0 or 1 in cnt, then starts counting up from there?
Does any of this sound like it could happen? What is everyone's thoughts on the cnt not starting at 0. How large does the cnt get before it will start over?
And this is why I suggested to move DAT variables to VAR sections - if they exist at all ... did not have a look into the video driver for a while.
Other HUB RAM used by all vCOGs could also be the problem.
Being a 32bit register, 2^32 cycles (best part of a minute @80MHz).
I have a different theory to offer here (admittedly a bit weak). I've seen video driver code which doesn't give the video PLL time to startup before issuing a waitvid. And I know from experience that not waiting can give you rather odd timings below a certain frame count. Anyway, there'd have to be a big unknown to account for the 1min delay which seems to be common ground here.
-Phil
Note that I don't know enough about Joms' code to comment on but I assume that it suffers from a similar problem. Bean's driver fits a single line into 5120 clock cycles. For an active line about 700 cycles are spent in normal code and 3k5 in the video loop. That's 4k2 total which leaves us with 920 cycles breathing room. As the PLL clock runs at 128MHz this amounts to 1472 PLL cycles (frame count is 704 PLL cycles).
So something is pushing the timing beyond 5120 clock cycles (once). Well, it's like this: vscl is only actually used (i.e. loaded into the video h/w) once the internal frame counter reaches 0. This means the first waitvid - after vcfg enables the video h/w - delays for an unknown amount of cycles (max 4K PLL cycles). On my demoboard it looks like shown below. Each cog from 1 to 7 runs the timing test 4 times (first 3 shown), the first run shows a random value, subsequent runs keep the last written value which survives cogstop and even short power loss (quick test up to 1min). The frame count of 704 translates roughly to 440 system cycles ($1B8). From left: cog number, system clock cycles (hex) for first waitvid and whole test sequence, last column is decimal PLL clock cycle count for the first waitvid.
1:[COLOR="red"]0000000E[/COLOR] 00000DDA 22 1:000001B4 00000F80 697 1:000001B4 00000F80 697 2:[COLOR="blue"]000009BF[/COLOR] 0000178B 3992 2:000001B4 00000F80 697 2:000001B4 00000F80 697 3:[COLOR="blue"]000009E6[/COLOR] 000017B2 4054 3:000001B3 00000F7F 696 3:000001B4 00000F80 697 4:[COLOR="red"]0000000C[/COLOR] 00001394 19 4:000001B3 00000F7F 696 4:000001B4 00000F80 697 5:[COLOR="red"]0000000C[/COLOR] 00001528 19 5:000001B4 00000F80 697 5:000001B4 00000F80 697 6:[COLOR="blue"]00000956[/COLOR] 00001722 3824 6:000001B3 00000F7F 696 6:000001B4 00000F80 697 7:[COLOR="blue"]000008B4[/COLOR] 00001680 3564 7:000001B3 00000F7F 696 7:000001B4 00000F80 697This shows that cogs 1, 4 and 5 favour rather short initial values while 2, 3, 6 and 7 come up with a rather high cycle count. The PropBASIC video examples use cog 0 and 1 so personally I wouldn't be able to see the negative effect (only 22/14 initial cycles which are not enough to break the waitcnt). That said, cog 2 would well be in range. The initial waitvid takes 2495 system cycles ($9BF). That's 2059 more than the expected value and as mentioned above, we only need about 900 to get into trouble.Data from a different demoboard: Once the intended frame count is transferred to the h/w it stays there until power is cut for an extended period of time (or the value is changed, obviously). Which also means that a manual reset will keep the value and a second run will now be based on the OK value. That's what everyone seems to experience.
Solution for the problem should be straightforward now, pending verification by people affected by this problem.
Merry Christmas!
As for the solution being straightforward, I must admit that I don't see it.
- set vscl
- enable video h/w (optionally with outputs disabled)
- issue dummy waitvid to purge the unknown register value
- disable video h/w
- enter frame loop
It doesn't matter for normal video drivers as they do their timing based on vscl only. So it sorts itself out. In combination with waitcnt one has to be more careful.Clarification regarding latched value
Once the frame counter reaches zero vscl is latched/re-loaded into the frame counter. Given that the PLL is still active it's immediately decremented. This means the longer you wait between the dummy waitvid and disabling the video h/w the smaller the remaining value will be (but it's never greater than the frame count).
You are a genius. I dont' fully understand, but I'll study it more.
Someone needs to alert Chip to this thread.
Bean
I put together a test program that starts Bean's overlay 4 times, but uses different pins for each video channel. Hopefully in a few hours I will have spent some time documenting it out and maybe fixing the problem. I will post any code updates or sample code when I get the comments on it...
THANKS!
FWIW, I validated the PropBASIC example in that I forced the MonoVid driver into cog 2 on my primary demoboard. This way I could in fact reproduce the startup delay due to waitcnt miss. Subsequent runs didn't show the problem. Adding code for purging the frame counter avoided the problem for the other high value cogs (3, 6 and 7) which previously exhibited the problem as well.
As a side note, removing the existing purge code from the overlay driver lets me reproduce the startup delay as well. With it enabled it just works for me. Let's see what Joms' code looks like.