Forum Discussion
Altera_Forum
Honored Contributor
16 years agoJake
At reset, the processor vectors to the base address of Flash (0X0a000000). Execution code is copied from Flash to DRAM. I'm still investigating, but I was able to see the Flash CE# assert 8.36 us after the CPU reset deasserts. I 'believe' that this is a Flash read (I'll know more today). I was also able to see the DRAM CKE signal assert 210 us after the cpu reset deasserts (DRAM clocks start 200 us before CKE asserts per DRAM spec). While this is not yet definite proof, I think that the data is being moved from Flash to DRAM correctly. The basic sequence looks right -- CPU reset deasserts, Flash activity, then DRAM activity. Last night, I had 2 similar thoughts to your recommendation. One was to hold the processor in reset longer than the memory devices. This would guarantee that both memory devices come out of reset before the processor uses them. The other thought I had is that maybe the CPU reset pulse width is not long enough. It could be that the the CPU reset is asserted during the final stage of the FPGA configuration, & ends BEFORE the config sequence completes. Maybe just making the CPU reset pulse longer will do the trick. In any case, thanks for your input. I'll let everyone here know how things go. Fred Oliva