hi this is sundaram from University of Waterloo. I'm current having a problem with the hello world template. I have been working on the FPGA for some months and it has always worked as expected. However, the last few days, I have a few problems from the software side. The Hello World Template isn't sending any messages to the JTAG UART. In fact, the small hello world with the printf is working perfectly.Do you guys have any idea?
The hello world small template uses a footprint optimized version of putstr() that doesn't rely on interrupts. Hello world uses printf and relies on interrupts to drive the communication back and forth. So make sure the interrupt line between the UART and CPU is connected. Also when you compile the code how much free space do you have for the Hello world software? That software typically needs around 67kB of memory.Since the memory footprints are different perhaps you have an issue on the memory side. What type of memory are use using to store your code? If it's an external memory then I would memory test it to make sure it's stable before using it to hold code. P.S. I went to the University of Ottawa..... many years ago :)
Hi thanks a lot for the quick reply. Regarding the design, I usually use the DDR2 Ram to store the executable code. So effectively, memory is not a problem. The problem is that, the designs that earlier used to work perfectly with the programs are not working these days. And again, printf() function works if I use it in the small hello world template. So, there's no problem with the printf() function as such.Thanks.. Nice to know that you are from here :-).
I looked at the hello world small template and in 11.0 it does not use printf so are you using an older version of the tools? At one time I think that software used alt_printf but I'm not sure when the change was made.I can't stress this enough though. Just because you can run code out of a memory doesn't mean it's functional. A processor doesn't typically stress a memory interface so I would make sure that memory is really functional (i.e. test it with a DMA) before ruling it out as a culprit. Also if you have not written off-chip timing constraints your design might work for one compile and fail for the next if you breath on it due to Quartus II not being provided enough information about your off-chip timing requirements.
If you only want to test your "hello world" template then you can select "onchip" memory as program memory (if lack of space then enable "small c library" from system properties)Try to run and see,if you are getting display or not. --- Quote Start --- Also if you have not written off-chip timing constraints your design might work for one compile and fail for the next if you breath on it due to Quartus II not being provided enough information about your off-chip timing requirements. --- Quote End --- @BadOmen:As sundaram said,small hello world is always working so i think it should not be timing requirements issue,is it??
A small program may fit in the cache better and minimize memory accesses. You could have a program that fills the entire memory and I still wouldn't consider it stable until that memory has been properly tested.
Hi sundargates,Did you ever find a solution to this problem? I'm running into the same issue. I'm running out of an on-chip memory of 131072 bytes which should be large enough. I also ran the small hello world and that worked fine. It looks like I have a problem with my interrupts but they appear to be hooked up correctly. Thanks, Scott
Your issue might be different. Do you have enough room for the stack and heap? Remember that when you allocate memory, use global variables, or have deep function calls (other things can cause this too) your stack and heap usage increases which isn't reported during compile time. If you run out of room then the stack and heap collide.One way to test this is to program your memory with a repeating pattern, run your code, then take a look at the contents to see if that pattern is still residing in the stack and heap regions. If the pattern is gone then the stack and heap most likely there was a collision. There are other ways to perform stack and heap collision but I don't have those details handy.
I was able to track down my issue by scraping my qsys project and rebuilding it from scratch. It looks like my generic tristate controller for my flash memory and the clock crossing bridge are breaking it for some reason which is strange since they're not being used at all right now. I'll definitely keep an eye on my memory usage in the future. Sometimes those messages fly by so fast it's hard to catch the important ones. Thank you for the info BadOmen.