Actually, SDRAM DOES take writes, IF, and here is the kicker, ALL segments (BSS, DATA, HEAP, and FEE) use the internal RAM. I can then launch my SDRAM tester and have it reliably verify all of SDRAM. The tester parses SDRAM into uint32 cells starting off with 0xFFEEFFEE in the first cell at 0x80000000, then reducing the count by one and placing the next data value, 0xFFEEFFED into the second cell, and so on. I would say a timing issue, however I wrote a simple function, which I placed immediately after the initialize SDRAM call, which increments a variable to 0xFFFFF before continuing, basically adding in a 1-second delay before the TI function gets called. Code still does not work. When I said the code comes up with .BSS in SDRAM was not true. The code comes up, but variable assignments do not take, basically my uninitialized static variables holding my commands. I would have to verify that specifically, but that seems obvious, as what else? Basically, my code simply does not like SDRAM for whatever reason, even though I can test SDRAM perfectly and repeatedly if all segments use internal RAM. I can honestly tell you that I have no clue where or how to answer your question about clocks in Halcogen . Can you tell me what tab you would like me to capture. I can tell you that I had the EE, when he was here, double and triple check the SDRAM values against the datasheet and he said that everything is fine. Like I said, the SDRAM tests are fine, as long as the linker does not have to touch/use/know about SDRAM. ;-) The EMIF General Setup | EMIF Clock is set to 10.000 MHz. Our main clock is set to 16 MHz, so as to be 100% compatible to the previous chip, the Intel 8036EX. Why do we have to be compatible? I have no clue. I got EE non-layperson speak as an answer. Here are the clock tree settings. I hope that answers your questions on clocks. If not, please let me know what you would like. The EE checked the table in the SDRAM, see above, against the datasheet several times. We also walked data, per test described above. He was satisfied with the result and said that future issues are software (CCS memory map, etc.), not hardware. I briefly looked at the datasheet and as I recall the settings were fine. Had the settings not been fine, my SDRAM test would not have worked. It seems to me the issue is a chicken and the egg type of problem. The SDRAM has to be initialized and operational prior to anything being done that uses it. I thought that was done with the "buffer = *PTR" assignment, not to mention my do-while-loop after that, but obviously not. Thoughts on next steps?
↧