| |
In lugnet.robotics.nxt.nxthacking, Jeremy Rand wrote:
> 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.
It is nice with some action.
>
> 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. • OK, that is very good.
>
> 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
A quick question: Are you running binsert after you compile? It may be
worthwhile to look at lines 50-55 in "Makefile". With some effort and a hex file
editor you can check if your VM modifications overwrite the files inserted by
binsert.
> 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.
I am sometimes using this simple snippet of code to see how far the code runs
(before a crash):
// GPIO pins
// See AT91SAM7S256 LEGO MINDSTORMS HW sheet 1
// and J7, J8, J9, and J6 on sheet 3
#define DIGIA0 (23) // Port 1 pin 5 (yellow)
#define DIGIA1 (18) // Port 1 pin 6 (blue)
#define DIGIB0 (28) // Port 2 pin 5
#define DIGIB1 (19) // Port 2 pin 6
#define DIGIC0 (29) // Port 3 pin 5
#define DIGIC1 (20) // Port 3 pin 6
#define DIGID0 (30) // Port 4 pin 5
#define DIGID1 (2) // Port 4 pin 6
// See HW appendix page 1. Pin5 on port 1 is PA18 that is DIGIA1
#define LEDVAL_ (1 << DIGIA0)
// Little function to toggle a pin
// Usage: write {toggle(0);}
// in your code to turn off the led
#define togglepin(toggle) {/* GPIO register addresses */\
/* Register use */\
*AT91C_PIOA_PER = LEDVAL_;\
*AT91C_PIOA_OER = LEDVAL_;\
if(toggle == 0)\
*AT91C_PIOA_CODR = LEDVAL_; /* port 1 pin 5 at 0.0 v (enable this line
OR the next)*/\
else\
*AT91C_PIOA_SODR = LEDVAL_; /* port 1 pin 5 (blue) at 3.25-3.27 v (GND
is on pin 2 (black)) */\
while(1); /* stop here */\
}
You can have it sitting in a header file or something, include the header file
and then write {toggle(0)}. It let's you plug in the light sensor in port 1 and
turns it off when the code reaches the toggle code. It is not tested on NXTGCC,
but with a firmware that is not running LEGO VM, so now you are warned.
>
> Any help would be greatly appreciated.
>
> Thanks in advance.
Thanks,
Rasmus
PS: You could/should post a link to you VM when it is done:-)
>
> -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
|
| Sorry I didn't have time to reply to your post yesteday; I had limited time available. (...) Hmm, as I said yesterday to Dick, disabling all three binsert calls in the makefile caused my firmware to crash on a blank screen, even after I had done (...) (17 years ago, 29-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
|
|
|
|
