Debugging your DIY serial interface
Posted: Fri Jan 25, 2013 4:05 pm
First check power and ground (check them again, if I had a $1 for every time
that was the problem ...)
Wiggle the serial IO lines you are using and make sure you see them wiggle on
the serial device you are trying to talk to. A scope is nice, but a logic probe
is good enough (a meter if its slow)
FOR I = 1 to 100
IO(SDATA_PIN) = I and 1
WAIT(200)
NEXT I
Do it for all the pins (clk, data, frame if used)
For I2C check that a device is detected by the ARM code. The 9th bit will be
held low by the slave if it has been addressed. Here a scope is nice, but a
logic probe will still do, by inserting a STOP in the i2c BASIC code where the
acknowledge would be detected.
Assuming you've got this far, pick a simple register that you can read and write
in the target device. Write a simple program to do that. If that doesn't work,
then maybe you have the address or command wrong.
Once this works, you can try the application. If you can write to a register,
but a string of commands don't work, re-read the specs. It might be you have
the data wrong, or it may be a timing issue. Some i2c devices are quite slow.
You may have to slow down the i2c shift rate. You may have to wait between
commands too.
i2c REQUIRES a pullup resistor on BOTH SCL and SDA, it will not work without it.
The BASIC and C code may hang without it, as part of a multi-master protocol is
to wait for BOTH lines to be high (if they are floating they may have floated
low).
The BASIC and C routines do not support multi-master i2c, nor do they support
clock stretching by the slave. This can be added to the bit banged routines by
changing the source code. It was not added, as few devices use it and it slows
down the bit rate.
Since this a number of debug tools have been added to BASICtools and TclTerm that allow you to wiggle both control lines and the RXD (to the ARM)
that was the problem ...)
Wiggle the serial IO lines you are using and make sure you see them wiggle on
the serial device you are trying to talk to. A scope is nice, but a logic probe
is good enough (a meter if its slow)
FOR I = 1 to 100
IO(SDATA_PIN) = I and 1
WAIT(200)
NEXT I
Do it for all the pins (clk, data, frame if used)
For I2C check that a device is detected by the ARM code. The 9th bit will be
held low by the slave if it has been addressed. Here a scope is nice, but a
logic probe will still do, by inserting a STOP in the i2c BASIC code where the
acknowledge would be detected.
Assuming you've got this far, pick a simple register that you can read and write
in the target device. Write a simple program to do that. If that doesn't work,
then maybe you have the address or command wrong.
Once this works, you can try the application. If you can write to a register,
but a string of commands don't work, re-read the specs. It might be you have
the data wrong, or it may be a timing issue. Some i2c devices are quite slow.
You may have to slow down the i2c shift rate. You may have to wait between
commands too.
i2c REQUIRES a pullup resistor on BOTH SCL and SDA, it will not work without it.
The BASIC and C code may hang without it, as part of a multi-master protocol is
to wait for BOTH lines to be high (if they are floating they may have floated
low).
The BASIC and C routines do not support multi-master i2c, nor do they support
clock stretching by the slave. This can be added to the bit banged routines by
changing the source code. It was not added, as few devices use it and it slows
down the bit rate.
Since this a number of debug tools have been added to BASICtools and TclTerm that allow you to wiggle both control lines and the RXD (to the ARM)