You have already lost more time and effort in this mess than a cheap scope costs.
In its own weird way, it is interesting to follow how long the guesswork will still last.
Methinks that you should start with putting the transmitter empty test before writing to the UART, to put the horse before the cart and not the other way round.
-- Tauno Voipio, and old and grumpy MSEE
It stops all output immediately. There might be a reason why Microchip's sample code test it after writing, not before.
I am entirely ignorant of Microchip devices... but this suggests a "stupid" question: are you sure that your "transmitter empty" test is using the correct logic sense, and is not a "transmitter not empty" test?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Yes, by flattering (coping) Microchip directly. For PIC32, there is even a NOP before testing. My quess is that they don't want some registers to be touched while transmitting.
you
I recently picked up a free scope on Freecycle, along with a lot of other electronics.
-- You can't have a sense of humor, if you have no sense.
Is some output received? Or is there no output at all?
I wouldn't call that "being sure"... rather, "being trusting". It is not unknown for example code to have bugs.
If you test UART register status after writing, and your test is really "is the register full", it will usually work, because you have just written to the register, so it is full. Your code then fetches the next byte to be sent, from wherever it is stored, and if that usually takes longer than the time the UART needs to transmit a byte, the register will have cleared in time, the next byte will go off correctly, and it will all seem to work.
The fact is, your app does not work; so there is an error somewhere (but of course perhaps not in the SW). The fact that your app works differently when you test UART register emptiness before writing to the register, and after writing to the register, is fishy. I would make very sure that the check for register emptiness is done correctly, and is not inverted.
HTH,
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
On a sunny day (Tue, 4 Oct 2011 11:12:23 -0700 (PDT)) it happened linnix wrote in :
There is no guarantee that the Microchip examples are correct. I know of at least 2 cases where they are not. And have read of one case that cost somebody a lot of money as they had to bring in a consultant to fix it. There is not even a guarantee the datasheets are correct or complete (examples exist) and no guarantee the hardware is correct, see silicon updates. Never assume, but measure, read those dataheets over and over again... Write test code.
No output at all. The chip seems to lock up.
U1TXREG =3D ch; Nop(); while(U1STAbits.TRMT =3D=3D 0);
bit 8 TRMT: Transmit Shift Register Empty
0 =3D Transmit Shift Register is not empty, a transmission is in progress or queued.unless the spec and sample codes are both wrong.
I'll try reversing the test and see what happens.
t y t
The chip lock up if I reverse the test. So, the existing spec and code should be correct.
You're looking at the wrong bit. You should look at the UTXBF bit and wait until it is zero.
The TRMT bit is intended for code controlling TX enable in line driver for e.g. RS-485.
-- Tauno Voipio
y t
ut
ery
ot
OK, will try it. If that's the case, Microchip is putting out wrong demo code for every serial appt for PIC18,24 and 32.
y t
ut
ery
ot
Checking TRMT bypass the transmitter buffer.
Checking UTXBF should be correct. However, it garbles the first few characters upon reset.
Will try two sets of routines and see if it works.
works
=A0I can
y to
00 bpscycle,
lem.
ge
rge
ert
le?
the
le
To which pins did you map the UART? And did you lock the IO mapping afterwards?
works
=A0I can
y to
00 bpscycle,
lem.
ge
rge
ert
le?
the
le
To which pins do you have the UART mapped? Did you lock the IO after mapping?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.