view gsm-fw/lldbg/README @ 884:353daaa6014d

gsm-fw/gpf/conf/gsmcomp.c: increased max partition in the voice-only config The code we got from TCS211 had the maximum prim pool partition size set to 900 bytes in the voice-only config (no FAX_AND_DATA, no GPRS) and to 1600 bytes in every other config. As it turns out, this "minimized" config breaks when the AT command interface is used with %CPI enabled, as the responsible code in ATI does an ACI_MALLOC of 1012 bytes. TI may have considered this case to be unsupported usage (perhaps they didn't care about the combination of a voice-only PS with AT command control), but we do want this use case to work without crashing. Solution: I made the largest prim pool the same as it is with FAX_AND_DATA: 3 partitions of 1600 bytes.
author Space Falcon <falcon@ivan.Harhan.ORG>
date Sat, 27 Jun 2015 07:31:30 +0000
parents f5affe83ba2d
children
line wrap: on
line source

The hack implemented in this directory is a poor girl's substitute for JTAG,
concocted for the purpose of debugging hard crashes in the firmware.  The
intended usage is that the developer seeking to troubleshoot perplexing
misbehavior in the firmware inserts a call to lldbg_entry() as a form of
breakpoint at the earliest place in the main fw where it is seen that something
has gone astray, and when the thread of code execution hits this lldbg_entry()
function, the regular Nucleus environment gets completely frozen.  Lldbg entry
code saves all registers and the return address (LR) on whatever stack it is
was called on, then disables all interrupts and switches to its own stack which
is not used by any other part of the fw.

This lldbg code is linked together with the main fw when feature lldbg is
enabled in build.conf, but it stands as its own separate body.  All functions
and variables within lldbg are prefixed with lldbg_ to avoid any clashes, and
once this lldbg code gains control, it does everything on its own without making
use of *any* part of the regular fw.  The code that forms lldbg is based on
FreeCalypso target-utils (loadagent) and is fully independent of the regular fw.

Lldbg uses its own UART input and output code as well: the entry code waits for
any previous output (presumably RVTMUX) to go out, then sends out an STX-wrapped
message to make the lldbg entry visible in rvtdump/rvinterf, preceded by 3 STX
characters to terminate any RVTMUX packet in progress.  From this point onward
all further communication is done in an ASCII terminal fashion: upon seeing the
lldbg entry message, the user needs to kill rvtdump/rvinterf and switch to
fc-serterm.  All lldbg code runs with interrupts disabled, thus UART input and
output are polled.

Once in lldbg mode, the user (developer) can execute various memory dump
commands to see the frozen state of the fw upon lldbg entry, and hopefully
figure out what went wrong earlier.