NiosII printf() not printing correctly

Hello,

I found a direction to search in:

If I enable "support small libary" in de Nios II BSP properties, the code works fine.

If the Small C library is disabled, i assume Newlib is used, under these conditions the bug presents itself.

So my revised question is: What could be the cause of this problem: my current working hypothesis: problem with Newlib?

Hello,

Again a little bit closer: it seems that the processor executes code marked in gray. This could mean that, according to the compiler, the code was not to be compiled (missing L_udivdi3 and the likes) but the debugger shows that the processor executes the 'stale' code.

Hello,

I have narrowed the problem down to a specific location in the newlib file vfprintf.c.

At line 1987 there is a statement " _uquad /= 10;" at that point, if the processor executes this function with _uquad = 12, _uquad becomes null instead of 2, this is the culprit causing the second digit of the printf output to be wrong. The reason why is a mistery for me. If i try an integer divide in the main routine, it works perfectly and is executed in the hardware divider of the processor.

The divide in the vfprintf.c was compiled to a software divide, when newlib was created. It is this routine that is not working properly (i think).

I assume that recompiling newlib for my current configuration might be the solution but i have no clue how to do this.

In the project makefile there is a section that starts with ifneq ($(COMPILE_NEWLIB),) i think i need to activate this section. But i a add COMPILE_NEWLIB 1 to the# symbols defined in the properties window of my project the newlib is not compiled.

Could anybody tell me if

1) If compiling Newlib is the solution to my problem.

2) How to trigger the newlib compile in from eclipse (i am just a beginner)

Thanks in advance for all the help I can get.

John.

I think i found the culprit. Anyway it works on my DE0-CV

The pll settings to control the SDRAM should be barrowed from the demo app from terrasic (CD with board) and not the settings from the Altera university tutorial.

Best Regards,

John.

Hello All,

I received a question from a forum member with the exact location of the files:

It is under the "Demonstrations" Subdirectory "DE0_CV_SDRAM_Nios_Test".

Last week, after many months of silence, i was happy to receive some feedback from Altera themselves regarding this issue. This as the feedback to the fact that i submitted my project for further investigation. They also concluded that there was a problem with the PLL Settings. What they did not conclude was that the basic culprit seemed to be a faulty component in the altera university blocks at that time.

My conclusion: be careful with the <System and SDRAM Clocks for DE-series Boards> clock. What i would advise is to use the PLL from the ALTERA Basic functions and copy the settings from the demo board CD to the standard Altera PLL. This is also the Terrasic proposal of doing things not the solution from altera university documents.

Best regards,

Johi.