Umon command line reached in BBB

Ed Sutter ed.sutter at
Thu Jun 18 11:29:19 UTC 2015

Some tips for debugging this...
Keep in mind that the code works, so think about what is new to the 
The memory map is the first thing I would look at...
Make sure you're stack (MONSTACKSIZE) is large enough, see if you're 
actually running
out of SRAM (I doubt that's it), etc...
My guess is that for some reason stack is getting corrupted or overflowed.
> I did some investigating as to why the 'help' command was hanging in
> the BBB.  I am just going to specify the general order of function
> invocations to help put the situation that I will try to describe into
> context.
> The Umon command line is presented in start.c via CommandLoop() and
> any commands entered are passed to docommand().
> Entering 'help' causes the command to be search through a command
> table where Help() is soon invoked in docmd.c.  Help() then calls
> showhelp().  I was able to pinpoint that program execution hangs at
> the very last printf in showhelp().  This printf is
> "printf("%-12s",cptr->name);
> Removing the "-12" between '%' and 's' eliminates the issue of program
> execution hanging but the format of the output is not justified
> correctly.  Diving more deeper into the printf(). vsnprintf() in
> mprintf.c is then invoked, followed by build_string(), then atoi() and
> then finally strtol() in strtol.c.
> The do/while loop in strtol() runs for one interation and then program
> execution seems to hang in the 'while' conditional where isspace() is
> invoked.  Based on my understanding, this do/while loop should execute
> more than once, but its not.
> Its 2:40 AM here at the time of this post, I will be investigating
> more into this after I get some sleep.
> Hopefully I did not miss anything.
> Any suggestions will be much appreciated.
> On Wed, Jun 17, 2015 at 4:09 PM, Jarielle Catbagan
> <jcatbagan93 at> wrote:
>> Ed,
>> I apologize for the misinterpretation/confusion.  My brain was
>> thinking one thing but I managed to state something else.  What I
>> actually meant to say was that some commands will not work just yet.
>> Like the ARP, DHCP, or any of the TFS commands since the ethernet and
>> flash drivers will have to be implemented first.
>> I am still analyzing the results that I got, in particular when I
>> executed the "help" command.  I am going to start looking into why its
>> hanging, i.e. no help text is outputted.  Just wanted to ask, do you
>> have any idea why it might be hanging?
>> On Wed, Jun 17, 2015 at 3:57 PM, Ed Sutter <edsutterjr at> wrote:
>>> Jarielle,
>>> Those commands will work as long as you access valid memory.
>>> Ed
>>>> Going off of the discussion that I had with Ed in regards to getting a
>>>> fully internal SRAM mapped Umon image to work before proceeding to
>>>> implement the DDR3 configuration to have the RAM used by Umon mapped
>>>> there, I went ahead and started working on it.
>>>> I configured the Umon image to be fully mapped within the internal
>>>> SRAM of the AM335x (i.e. BOOTROMBASE/BOOTRAMBASE defined to be within
>>>> the internal SRAM with their corresponding lengths ensured to not
>>>> overlap each other and to not exceed the SRAM boundaries), and then
>>>> enabled INCLUDE_MEMCMDS by setting it to test the DM and PM commands.
>>>> I know that these commands will not work properly given the fact that
>>>> DDR3 is not set up yet, but just wanted to see if some command
>>>> execution is possible.
>>>> I then proceeded to build the image and then booted the image on the
>>>> BBB via UART.  Once booted, the Umon command line was presented and
>>>> did some command execution testing.  Nothing works properly as of
>>>> right now, but now that I am able to reach the Umon command line I can
>>>> now proceed to getting the other functions implemented.
>>>> My results of getting the Umon command line on the BBB can be found in
>>>> the screen capture provided below.
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at
> _______________________________________________
> umon-devel mailing list
> umon-devel at

Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email: ed.sutter at

More information about the umon-devel mailing list