'Flush' fprintf

SamMeredith · Joined: 13 Jul 2018 Posts: 23

Pic: DSPIC33EP512MC806
Compiler Version: 5.093

I have serial output set up for debugging:

Ttelmah · Joined: 11 Mar 2010 Posts: 19215

The output takes place as fast as it can. So there is nothing you can do
to speed it up. You just have to add code to wait while the port has
any data to send.
Normally on a UART, you could wait while the TBE bit is not set.
So in your case use a #bit to allocate the TBE3 bit, and wait for this
to go high.

jeremiah · Joined: 20 Jul 2010 Posts: 1315

For PIC24/dsPIC, you can watch the TRMT bit (see the datasheet for details).

It's been a while, but if you create the TRMT variable using #bit, then you can do something like this:

Ttelmah · Joined: 11 Mar 2010 Posts: 19215

Yes. TRMT is better. On the PIC24, this reflects both the shift register and the
buffer register being empty.
Use this.
It's a '1' when the buffer is empty. So wait while it is low.

#define u3_flush() while(U3TRMT==0){}

SamMeredith · Joined: 13 Jul 2018 Posts: 23

Thanks!

I have defined u3_flush() as you both suggest. Seems to be working well.
Now to find the bug itself...

Ttelmah · Joined: 11 Mar 2010 Posts: 19215

The hard bit..... Very Happy

I'm having one at the moment, with fp maths (fifth order polynomial) being
done on four PIC33's, occasionally triggering #INT_MATHERR. If I don't trap
this, the chip crashes. I've had to add a flag, and set this in the MATHERR
handler, then after the arithmetic, if this is set, invalidate the number
returned. There doesn't seem to be a 'tidy' way to handle this presently
in the compiler.
Took some tracking down... Sad

SamMeredith · Joined: 13 Jul 2018 Posts: 23

That does sound nasty.
I'm not that familiar with traps, #INT_MATHERR triggers on an attempted divide by 0?
If it were as simple as that you'd have caught it in the code, so it must be a fp precision error part way through a calculation that turns a small (but not actually 0) value into a 0?
Well beyond my level, but I came across an article on hackernews yesterday on fp error analysis.

What would you like to happen in an ideal compiler?
Some way to give up on the calculation as soon as #INT_MATHERR triggers?

I've located my bug. The CCS TCP/IP stack detects an invalid MAC header from the ENC28J60 chip I'm using and resets the PIC in response.
I'm unsure why a) it resets rather than just discarding the packet and b) it happens on this project and not others using the same circuit.

temtronic · Posted: Thu Aug 06, 2020 8:08 am

Ttelmah · Joined: 11 Mar 2010 Posts: 19215

Yes.

On my maths error. This is an internal division sub,
inside the fp maths, not necessarily a actual division by zero. I'd have
to take the fp routines apart to find what is actually triggering it, but it
seems that some particular fp values are resulting in a /0 trigger.
Now the compiler does have a maths error 'errno', which is meant to
be set if an operation involves a /0. However the hardware error trips,
rather than this being set.

In your case I'd suspect that some issue with the particular chip/setup,
is triggering your error. Not something like you have the WDT enabled
on this project and not the others?.