| |
Sorry I didn't have time to reply to your post yesteday; I had limited time
available.
> 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.
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
what Dick said, which on its own allowed the NXT to at least display some
garbage pixels before crashing. Is that the expected behavior? If the firmware
size grows such that I am forced to change the #defines for the start of user
flash, what changes would I have to make to how binsert is called in the
makefile?
> I am sometimes using this simple snippet of code to see how far the code runs
> (before a crash):
> <snip>
Thanks, that will probably come in handy.
> PS: You could/should post a link to you VM when it is done:-)
I believe I will (assuming my employer is okay with it, but they should be),
although I don't know when or if the new VM will be finished. :-)
Thanks,
Jeremy Rand
|
|
Message is in Reply To:
 | | Re: Custom firmware crashing on boot
|
| (...) It is nice with some action. (...) OK, that is very good. (...) 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 (...) (17 years ago, 28-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
|
|
|
|
