Mark,
Thanks and I agree, except I have been working with these chips on the NE64 for the past 6 years (ok, I used the 1MB version of the SPI at the start) so debugging on a real system is easy for me and I am more used to that than checking everything out with the simulator.
Now with that in mind, I may have found an issue still with selection of the proper chip. My previous post was a bit in error in that it turned out uTasker was STILL selecting the first chip even with all the address correct.
So what I found (when I do a DIR command from ftp) was this. I will attempt to show this as basic flow in uTasker...
At the dir the processing path goes as follows along with the virtual starting address value as follows (=> means called from previous routine/system)
=>fnDoDir (starting address not set)
=>uOpenNextMimeFile (starting address passed as zero to force it to set)
=>uGetFileLength (starting address is now set uFILE_SYSTEM_START
value which is 0x00640000)
=>fnGetParsFile (NOW, inside the routine, the address is zero)
=>fnGetSPI_FLASH_location (starting address is zero)
=>fnGetSPI_Device (starting address is zero and the returned chip is 0)
So I do not know if maybe I have an optimization issue or what, but this loss of the starting address is what I did see in the simulator.
Now something even more interesting, if I hard-code the chip-select value to 3 in the fnGetSPI_FLASH_location instead of calling fnGetSPI_Device, everything works perfectly (really!!) and when I debug, I notice that I do NOT loose the starting address at all (as I am not using it to determine which chip) throughout the 'same' sequence I described above.
In any case, I will leave it hard-coded for now as this will remain this way for this device. Just figured I would let you know what i found.
Thanks.
- jon