[fpc-devel] Embedded Strings on nRF51-DK

Michael Ring mail at michael-ring.org
Wed Apr 29 09:15:12 CEST 2015

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 ?


JLinkGDBServer -if swd

Then for very low level debugging you can do:

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 

For source code debugging the nicer solution is to use cgdb:

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

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.


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 at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20150429/9922318b/attachment.html>

More information about the fpc-devel mailing list