One question, why do you enable flow control? Afaik the serial interface
only uses rx/tx.
For the strings problem, I guess it's time to start up the debugger ;-)
(I am removing the dust from my nrf51 dongle, too ;-) )
It looks like you are on Linux, can you please install cgdb and make
sure that you also have arm-none-eabi-gdb ?
Start
JLinkGDBServer -if swd
Then for very low level debugging you can do:
BIN=hello.elf
arm-none-eabi-gdb $BIN --tui --eval-command="target extended :2331"
--eval-command="monitor reset" --eval-command="monitor halt"
--eval-command="set mem inaccessible-by-default off"
--eval-command="load" --eval-command="layout asm" --eval-command="layout
regs"
For source code debugging the nicer solution is to use cgdb:
BIN=hello.elf
cgdb -d arm-none-eabi-gdb $BIN -- --eval-command="target extended :2331"
--eval-command="monitor reset" --eval-command="monitor halt"
--eval-command="set mem inaccessible-by-default off" --eval-command="load"
When cgdb is up you can first do:
break main
cont
cont
then hit 'ESC', you are now in the top window, with F8 / F10 You can
step over/into your code,
hit i, then you are back in the lower window and can inspect variables.
Michael
Am 28.04.15 um 23:43 schrieb Paul Michell:
Micheal,
I have started to encounter problems with the UART handling. Test4 starts to
add some program logic and construct debugging messages back through the UART
functions.
The first problem is a corrupting of the system start message, although
subsequent message output is fine? This can be seen in the attached image.
Strangely, I have found by trial and error, that removing:
GPIOOutputPin(TXDPinNumber);
from the UARTConfigure procedure (which is a line-for-line translation of the
original GCC function) makes this issue go away! I don't understand why this
happens, nor if it is safe for me to leave out this line permanently from the
procedure?
Secondly, the run counter should be formatted by the string expression:
MessageText := 'Run: '+IntToStr(RunCount)+#13#10;
UARTSendString(MessageText);
All that is actually printed is the RunCount number. This can also be seen in
the screen shot. I wonder if there is some aspect of the string handling that
is still not being linked? If so, would it be possible to fix this, as this
sort of trivial text construction is a major benefit of Pascal over C.
I have also managed to get button input working and some initial success with
using timer interrupts rather than the rather clumsy wait loops included in
these tests. At the moment this code still uses my old nRF51 header
translation. I will next work on converting these to use your header layout.
I would be happy to post these here if anyone would like them?
After this I want to start looking at how to use the RF/Bluetooth softdevice,
has anyone else tried this yet?
Thanks,
Paul
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
