Subject:
|
RE: Custom firmware crashing on boot
|
Newsgroups:
|
lugnet.robotics.nxt.nxthacking
|
Date:
|
Wed, 27 Jun 2007 23:10:11 GMT
|
Reply-To:
|
<dickswan@sbcglobal^NoMoreSpam^.net>
|
Viewed:
|
16028 times
|
| |
|
|
Here's two things to try since you've only swapped out the VM hich I
assume is a replacement for the "c_cmd.c" file.
1. First there is a "#define" that specifies the start address of the
file system. If you're 10K larger you're going to need to change this.
2. Next patch out all calls to your replacement VM. The easiest way to
do this is simply with a "return" inserted at the beginning of the
"cInit", 'cCtrl" and "cExit" functions in the "cCmd" extern structure.
This will completely disable your code and remove it from being
called. If you do this, and the compiler has a decent code optimizer,
your object file will be at least 10K (more like 20K) and you won't
have to figure out (1) to at least try this.
If you do above and it now works, then you now know where to look.
TO incrementally get your code functional, I would suggest the
following steps.
1. Use one of the PC based communications programs to ensure that USB
communications protocols are operational via the Fantom.dll. Any of
the NXT-G, RobotC or BricxCC IDEs will be able to do this for you;
they may hiccup part way through but if they work enough to get a few
of their initial messages through then it's reasonably confident that
the comms system is working -- they may hiccup on things like
mismatched versions or trying to use extended messages not in your
firmware.
2. Look at the file "m_sched.c" and you'll find how your code gets
executed by the "scheduler". Re-enable "cInit" function first and make
sure it works. Then un-patch "cCmd".
3. Figure out how to get some debugging traces working that puts stuff
on the LCD display.
4. Put some progress messages within c_cmd to tell you what's getting
executed.
Hope above helps.
If you get really stumped after trying above, and you've really only
changed "c_cmd'c", then send me your version of that fileand I'll
compile and load it with my IAR JTAG tools and I can tell you where
it's failing.
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On
Behalf Of Jeremy Rand
Sent: Wednesday, June 27, 2007 4:37 PM
To: lugnet.robotics.nxt.nxthacking@lugnet.com
Subject: Custom firmware crashing on boot
Hey, I'm new here, so if I seem like a n00b, it's probably because I
am. Hopefully my question won't be too annoying.
I'm trying to use the NXTGCC 0.0.9 package as a starting point for
custom firmware. The main point of my custom firmware is to swap out
the virtual machine for a custom one. I can compile the NXTGCC
firmware fine, and it loads with SAM-BA and works.
My modifications to the firmware so far are disabling a few parts of
the NXT-G virtual machine (by commenting out some parts of c_cmd.c),
and inserting a new file containing the implementation of the new
virtual machine. I inserted into c_cmd.c some code which (hopefully)
is supposed to translate calls to the NXT-G VM into calls to the new
VM. It now compiles fine, however, when I load the firmware with
SAM-BA and type "go 0x100000", the NXT crashes with a blank screen,
and I have to put it back in SAM-BA mode and load a working firmware
to make it function again.
Very little of my changed code executes on boot, all of which I am
relatively confident is not likely to cause a crash. Is the VM
normally called during boot? I don't believe so, but if someone can
contradict me, that would be helpful information.
My hypothesis (which is likely wrong, but it's the only one I have --
help would be appreciated here) is that maybe parts of the firmware
are being overwritten by the file system or something, since the new
firmware is around 10KB larger than the NXTGCC firmware.
The address table thingy (not sure what it's called -- again, I'm a
n00b) outputted when I make the new firmware is as follows:
Size after:
m_sched.elf :
section size addr
.text 126572 1048576
.text2 23072 1279744
.data 6180 2097152
.bss 46604 2103332
.comment 2970 0
.debug_aranges 592 0
.debug_pubnames 95 0
.debug_info 4366 0
.debug_abbrev 1012 0
.debug_line 3349 0
.debug_frame 276 0
.debug_str 353 0
.debug_loc 3214 0
.debug_ranges 456 0
Total 219111
Not sure if this helps in diagnosing the problem or not; if there's
any more detail I need to provide for people to get an idea of what
could be wrong, just ask.
Any help would be greatly appreciated.
Thanks in advance.
-Jeremy Rand
PS: I attempted to post this message two days ago, but I believe it
got eaten by my client. If anyone receives a duplicate, I apologize.
--------------= Posted using GrabIt =----------------
------= Binary Usenet downloading made easy =---------
-= Get GrabIt for free from http://www.shemes.com/ =-
|
|
Message has 1 Reply:
 | | Re: Custom firmware crashing on boot
|
| (...) The modifications are slightly more complex than simply replacing c_cmd.c, but that's basically the only NXTGCC file that I've modified. The new VM is copied mostly verbatim from another program, and is contained in a new file, pcodesim.c. (...) (17 years ago, 28-Jun-07, to lugnet.robotics.nxt.nxthacking)
|
Message is in Reply To:
| | Custom firmware crashing on boot
|
| Hey, I'm new here, so if I seem like a n00b, it's probably because I am. Hopefully my question won't be too annoying. I'm trying to use the NXTGCC 0.0.9 package as a starting point for custom firmware. The main point of my custom firmware is to swap (...) (17 years ago, 27-Jun-07, to lugnet.robotics.nxt.nxthacking)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
