Tried:
- configuring to less than configMAX_SYSCALL_INTERRUPT_PRIORITY the priorities
of IRQs which have handlers that use FreeRTOS API ISR-'safe' functions to
<give> semaphores, queues
- adding counters to see how many times the IRQ fired, and how many times
the task fired
- etc., etc.

A bug was fixed in gps_parse_nmea(), whereby the wrong buffer was
given as a param to strlen(), which is used in gps_parse_nmea() to
provide a buffer size parameter to nmea_parse.

After this, the processor now enters a hard fault ,probably due to
segmentation fault. More debug is needed probably with a different
board to find out why.

The issue was the SysTick timer, which was configured by the bootloader to
blink the backlight LEDs, but was not de-configured before booting to the
application.

Without the SysTick timer de-configured, the FreeRTOS tick timer, which relies
on the SysTick timer, fired before FreeRTOS could be properly configured. Since
the FreeRTOS SysTick handler contains some OS-specific functions and data, the
fact that these were not initialized probably led to a segfault.

This issue was fixed in boot.c, by de-configuring the SysTick timer.

Some open-field testing needs to be performed on GPS reception, as the GPS
readouts are ~1 arcsec. off from reference Android app (`My GPS Coordinates').
However, this does translate in 30m accuracy, so it's not a big deal.

Now pending processor unlock to test coordinate format display.

Tested, but not yet working. SW_BL makes loop pass, but no USB connection yet.

Broke one button, attempting to change files accordingly.

Again switching to Fede's branch

Note: the application still doesn't show the coordinates, just UTC
time received from sattellites.

The GPS icon blinks while searching for signal and is on when fixed

Note: still standalone, 'bear'-metal application, not yet hooked
to FreeRTOS

Implemented and tested some utility functions