Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12596 Discussions

printfs with no display console open cause back-up in another communication FIFO

Altera_Forum
Honored Contributor II
1,042 Views

Kind of a weird one here... 

 

I have a NIOS program which transmits to a Eth MAC through a dc FIFO 

and a few "adapters." 

All components are within an SOPC system. 

I have printfs present and thus a JTAG_UART is instantiated. 

I create a .sof which has NIOS code embedded. 

 

Loading the sof and then communicating with this device from the host 

through the ethernet interface back and forth(small replies) with 256 byte mem  

writes to write the EPCS memory(for remote upgrade, 1 page at a time) creates a  

problem where after a number of write/reply messages a reply is finally not provided. 

Most of the time this missed reply happens when the write is starting a EPCS 

sector which means the sector will get erased and thus causes a longer delay 

than the regular page writes. Note for this case Eclipse is _not_ being used to 

display the printfs. 

 

Thing is that if after this apparent failure in communication I run the NIOS elf file 

(same as was used to generate the .hex and thus .sof) from Eclipse and all 

the backed up printfs from the previous run come out through the console 

AND in wireshark the replies that never came now suddenly come out so the 

assumption is that they were backed up in transmit FIFO(s). 

Note that the 2nd run elf file could simply be a main() return 0; (ie. do absolutely nothing) 

and the result is the same. So, the back up of communication replies seems 

to be released by just loading/resetting NIOS. 

 

Also, if I run the regular .elf from Eclipse then there are no issues at all. 

ie. the whole EPCS memory is written successfully with no communication issues. 

 

So, I feel it is something related to the printfs and possibly a stall in  

the JTAG UART that is holding things up. 

 

I hope this is clear. Brain is a little cooked right now. 

 

Love to hear some thoughts on ways to resolve or debug this. 

 

Regards, 

 

Cos
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
245 Views

Hunch seems to have been correct about printf and jtag uart. 

 

Just added(borrowed from another thread): 

# define DEBUG_BUILD 0 

# define printf if (DEBUG_BUILD) printf 

 

and problem seems to have gone away. 

 

Cos
0 Kudos
Reply