After changing a quartz KyeDos can't see SD card at first power on. Reset don't help. You have to switch off power supply, then switch it on, then it can see SD. No matter, what is this change, from 5 to 6.25 or from 6.25 to 5 MHz. First power up after changing quartz - SD unavailable. Second power up, all ok. Works @80, 100, 112 MHz, you only have to reboot it twice after replacing a quartz.
This is not a problem, if it is known. Now I know: after any frequency change, reboot twice, and then it works. After this, system can see SD card after every boot.
I have a problem that I now think resides in the FATEngine...
I have a boot program that uses fsrwfemto. It loads a binary from the SD card and executes it. If that program also uses fsrwfemto or the later fsrw, everything is fine. However, if that binary uses Kye's FATEngine, the program hangs. I suspect the startup code in FATEngine is not properly resetting the SD card.
Any thoughts/suggestions???
Kye: This may be the problem. IMHO fatengine should be able to reset the SD card out of any mode. This could be the problem with other SD cards that fatengine cannot work with???
Do you have any info on how I could go about this Kye? I found that sometimes, even fatengine does not work after it performs an SD load. So it seems to me that it is an SD card reset/initialisation problem. I would really like to solve this if at all possible so that the fswr variants and fatengine can switch between them without problems.
I understand what you are saying, but, it's not really easy to get a card out of multi-block mode and it wasn't a top priority to code up, get working, and then test when I was writing this code 3.5 years or so ago. Whatever the case, its a won't fix now. Anyway, the attached file should get you operational.
Just run the start_explict command before launching the FATEngine to reset the SD card.
I just took the init code from the regular multi-block code in FSRW and commented out starting the block driver. You may have to comment out some more stuff to get it to run, but, I think I got it.
Kye, this did not fix the problem but I did narrow down the problem further. I use the old fsrwfemto which I don't think uses block mode. However, the problem appears not to be in fatengine not working, but rather that it cannot perform a fat.bootpartition - the file exists and the partition has mounted successfully.
The problem is a little deeper than this because I can load/run other modules so there is something that fatengine uses that is either not setup of I have corrupted. Any ideas?
Thanks Kye. I have no idea either atm. The program never returns from the bootpartition call. I think I will need to put some debugging steps in to post to hub where it gets to. I am thinking more like I am corrupting something.
Well, the checksum may have failed. When I first added the booting functionality it was really slow because I had to iterate over all the bytes in the image in SPIN one by one. This took forever, so I moved it into the ASM code, however, the cost was that there would be no error messages anymore if there was a failure but instead the system would just shutdown. Additionally, the word at address 6+7 must be 16. Otherwise my code just stops the system clock.
Thanks for the suggestion Kye. I have already tried this by patching out the checks (though after my post above).
What I have found is that I can make it work using two separate versions of your pasm...
1. One version effectively reboots a binary by stopping all other cogs. This is your unmodified code.
2. Second version used by my OS for all command binaries where the upper hub ram remains intact (the pasm loader section is modified to prevent overwriting the top part of hub ram), and not all cogs are stopped (I have a byte in top hub ram that I pass to your pasm) - ie I don't stop the current pasm cog, and I don't stop any others that I require to be resident.
Both the versions work correctly, but for some reason I cannot run a combined version (the second version should run like the first). Below is the affected code in case you can see what I believe is a bug of mine - it is the second version above and it should also load the full binary when my cog byte =0 and my hub_free=$8000 (I set these in my calling code if the file to be loaded is a ".BIN" file.
BTW I still have the problem that your FatEngine will not run after fsrw has been run. I still have not found this problem yet. Perhaps the fix attempts were masked by the above problem. Anyway I found a temporary way around both problems.
' /////////////////////////////////////////////////////////////////////////////////////////////////////////////
' Reboot Chip
' /////////////////////////////////////////////////////////////////////////////////////////////////////////////
rebootChip mov counter, #8 ' Setup cog stop loop.
cogid buffer '
rdbyte SPIExtraCounter, ptrHubOScogs '\ don't stop these cogs RR20120321
shl SPIExtraCounter, #24 '| and shift to b24-31
rdlong saveClockFreq, #$0 '| save the clock freq
rdbyte saveClockSet, #$4 '/ save the clock setting
rebootCogLoop sub counter, #1 ' Stop all cogs but this one.
cmp counter, buffer wz '
rcl SPIExtraCounter, #1 wc ' Dont stop this cog?
''RR20120321 replace next line
''if_nz cogstop counter
if_nz_and_nc cogstop counter ' Stop some cogs RR20120321
tjnz counter, #rebootCogLoop '
mov counter, #8 ' Free all locks. (07654321)
rebootLockLoop lockclr counter '
lockret counter '
djnz counter, #rebootLockLoop '
' //////////////////////SetupMemory///////////////////////////////////////////////////////////////////////////
mov counter, #64 ' Setup to grab all sector addresses.
rdlong buffer, sectorPntrAddress '
rebootSectorLoadLoop rdlong cardRebootSectors, buffer ' Get all addresses of the 64 sectors.
add buffer, #4 '
add rebootSectorLoadLoop, fiveHundredAndTwelve '
djnz counter, #rebootSectorLoadLoop '
' //////////////////////FillMemory////////////////////////////////////////////////////////////////////////////
mov readBlock, #0 ' Fill these two commands with NOPs.
mov readBlockModify, #0 '
''RR20120321 mov SPIExtraCounter, #64 ' Ready to fill all memory. Pointer at 0.
rdlong SPIExtraCounter, ptrHubFree '\ get top of hub clear limit RR20120321
shr SPIExtraCounter, #9 '/ /512 to get no of sectors
mov buffer, #0 '
rebootCodeFillLoop mov SPIextraBuffer, cardRebootSectors ' Reuse read block code. Finish if 0 seen.
tjz SPIextraBuffer, #rebootCodeClear '
add rebootCodeFillLoop, #1 '
call #readBlock '
djnz SPIExtraCounter, #rebootCodeFillLoop '
' //////////////////////ClearMemory///////////////////////////////////////////////////////////////////////////
rebootCodeClear rdword counter, #$8 ' Setup to clear the rest.
''RR20120321 mov SPIExtraCounter, fiveHundredAndTwelve ' \ $8000
''RR20120321 shl SPIExtraCounter, #6 ' /
rdlong SPIExtraCounter, ptrHubFree '> get top of hub clear limit RR20120321
rebootCodeClearLoop wrbyte fiveHundredAndTwelve, counter ' Clear the remaining memory.
add counter, #1 '
cmp counter, SPIExtraCounter wz '
if_nz jmp #rebootCodeClearLoop '
rdword buffer, #$A ' Setup the stack markers.
sub buffer, #4 '
wrlong rebootStackMarker, buffer '
sub buffer, #4 '
wrlong rebootStackMarker, buffer '
' //////////////////////VerifyMemory//////////////////////////////////////////////////////////////////////////
mov counter, #0 ' Setup to compute the checksum.
rebootCheckSumLoop sub SPIExtraCounter, #1 ' Compute the RAM checksum.
rdbyte buffer, SPIExtraCounter '
add counter, buffer '
tjnz SPIExtraCounter, #rebootCheckSumLoop '
and counter, #$FF ' Crash if checksum not 0.
tjnz counter, #instructionHalt '
rdword buffer, #$6 ' Crash if program base invalid.
cmp buffer, #$10 wz '
if_nz jmp #instructionHalt '
' //////////////////////BootInterpreter////////////////////////////////////////////////////////////////////////
jmp #noClockChange ' Dont change the clock RR20120321
rdbyte buffer, #$4 ' Switch clock mode for PLL stabilization.
and buffer, #$F8 '
clkset buffer '
rebootDelayLoop djnz twentyMilliseconds, #rebootDelayLoop ' Allow PLL to stabilize.
rdbyte buffer, #$4 ' Switch to new clock mode.
clkset buffer '
jmp #bootSpin '\ RR20120321
'|
noClockChange wrlong saveClockFreq, #$0 '| restore clock freq RR20120321
wrbyte saveClockSet, #$4 '/ restore clock setting
bootSpin coginit rebootInterpreter ' Restart running new code.
cogid buffer ' Shutdown.
cogstop buffer '
Comments
After changing a quartz KyeDos can't see SD card at first power on. Reset don't help. You have to switch off power supply, then switch it on, then it can see SD. No matter, what is this change, from 5 to 6.25 or from 6.25 to 5 MHz. First power up after changing quartz - SD unavailable. Second power up, all ok. Works @80, 100, 112 MHz, you only have to reboot it twice after replacing a quartz.
Strange...
Thanks,
I have a boot program that uses fsrwfemto. It loads a binary from the SD card and executes it. If that program also uses fsrwfemto or the later fsrw, everything is fine. However, if that binary uses Kye's FATEngine, the program hangs. I suspect the startup code in FATEngine is not properly resetting the SD card.
Any thoughts/suggestions???
My FAT Engine code makes no attempts to get a card out of multiblock mode. That's the problem.
Um, the thing to do would be to take the code from fsrw block driver that is in SPIN which gets the card out of multiblock mode.
Do you have any info on how I could go about this Kye? I found that sometimes, even fatengine does not work after it performs an SD load. So it seems to me that it is an SD card reset/initialisation problem. I would really like to solve this if at all possible so that the fswr variants and fatengine can switch between them without problems.
I understand what you are saying, but, it's not really easy to get a card out of multi-block mode and it wasn't a top priority to code up, get working, and then test when I was writing this code 3.5 years or so ago. Whatever the case, its a won't fix now. Anyway, the attached file should get you operational.
Just run the start_explict command before launching the FATEngine to reset the SD card.
I just took the init code from the regular multi-block code in FSRW and commented out starting the block driver. You may have to comment out some more stuff to get it to run, but, I think I got it.
Booting will fail only if there is a problem accessing the SD card or if the image is corrupted. Otherwise you should be fine.
What I have found is that I can make it work using two separate versions of your pasm...
1. One version effectively reboots a binary by stopping all other cogs. This is your unmodified code.
2. Second version used by my OS for all command binaries where the upper hub ram remains intact (the pasm loader section is modified to prevent overwriting the top part of hub ram), and not all cogs are stopped (I have a byte in top hub ram that I pass to your pasm) - ie I don't stop the current pasm cog, and I don't stop any others that I require to be resident.
Both the versions work correctly, but for some reason I cannot run a combined version (the second version should run like the first). Below is the affected code in case you can see what I believe is a bug of mine - it is the second version above and it should also load the full binary when my cog byte =0 and my hub_free=$8000 (I set these in my calling code if the file to be loaded is a ".BIN" file.
BTW I still have the problem that your FatEngine will not run after fsrw has been run. I still have not found this problem yet. Perhaps the fix attempts were masked by the above problem. Anyway I found a temporary way around both problems.