 | | Re: Alternate NXT-Firmware flashing tools
|
|
(...) Hi Matt, I think the problem is, that 99% of users using MS and Intel equipment... Minorities, like me, have always problems when using this :D I can't resist... Bye Christian (17 years ago, 29-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
(...) Hi Jürgen, just for information: nxjflash has the same problems at PPC and SPARC ;-( Next week I try to get a little endian machine and try it again... Thanx for your detailed informations Bye Christian (17 years ago, 29-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
Hi all, (...) Recently, we finished a runtime for the RCX, and discovered the awful state of uploading tools for that platform. In particular, there are at least three versions of firmdl running around the net, each capable handling different (...) (17 years ago, 28-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
Hi Christian, (...) if you have an endianness problem it should be visible. The easiest would be to compare it with a little-endian machine. (...) It uses the SAM-BA protocol, which is rather simple and without error checking, more like what a human (...) (17 years ago, 28-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
(...) ReHi Jürgen, yes this is a trivial job, but what should I learn from this packets ? fwflash returns no error back to commandline ... Does this mean fwflash works blindly and returns no protocol or packet errors ? Why is the result "success" (...) (17 years ago, 26-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
Hi Christian, (...) you could add some code in lowlevel.c to dump the USB packets, and then look if you see anything wrong. Jürgen (17 years ago, 26-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
(...) Hi Jürgen, very good idea. Please give me some hints where to start. I haven't found any --verbose command line parameters, yet :D OK, I'm trying to read the source again, expecting ENDIAN problems like every time using PPC and SPARC :-D Bye (...) (17 years ago, 25-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Alternate NXT-Firmware flashing tools
|
|
Hi Christian, (...) how about trying to fix fwflash? Jürgen (17 years ago, 25-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Alternate NXT-Firmware flashing tools
|
|
Hi NXT-Community, I'm searching for an alternate firmware flashing tool for the NXT... Using the Lego Mindstorms Software is an easy way to do this, but not available for my favorite operating systems. I've tried fwflash from libnxt, but without (...) (17 years ago, 25-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Messing with memory pool
|
|
(...) So you have not removed the line from cCmdInitPool where VarsCmd.Pool is set equal to IOMapCmd.MemoryPool, correct? Can you say where "mem" comes from and is it for certain being initialized to zero or nil before cCmdInitPool gets called? Is (...) (17 years ago, 20-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Messing with memory pool
|
|
(...) Okay, thanks for the tip. It was a bit unnecessary for you to spend two paragraphs on that, though; a sentence or two would have sufficed. :-) (...) Code is as follows: if (!mem) mem= (char*)(VarsCmd.Pool); memset(mem, 0, POOL_MAX_SIZE); I'm (...) (17 years ago, 17-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Messing with memory pool
|
|
(...) There is no such thing as an NXT-G memory pool. The standard NXT firmware has nothing to do with the graphical programming language implemented by LEGO and NI which is called NXT-G. (...) Why are you setting it to 0x00 if other parts of the (...) (17 years ago, 17-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Messing with memory pool
|
|
I'm working on a custom firmware with a new VM. I'm currently trying to reuse the NXT-G memory pool to hold data for the new VM, but I'm running into problems. Apparently, doing a memset to set all of the pool to 0x00 causes the firmware to crash. (...) (17 years ago, 16-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | binsert question
|
|
Starting with the original NXTGCC source, if I disable binsert in the makefile, the firmware crashes on boot. The firmware development which I am doing will probably increase the size of the firmware by around 20KB, so I'm wondering if I need to do (...) (17 years ago, 11-Jul-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | 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)
|
| |
| | Re: Adding a JTAG port?
|
|
(...) I used a JTAG tool in the beginning by glueing a JTAG connector manually. You could do that and perhaps have a look at section 4.3 in (URL) it is easier to use libnxt. I am using it in this project: (URL) can download libnxt source from (or of (...) (17 years ago, 29-Jun-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Adding a JTAG port?
|
|
Hi all, Do I need to add a JTAG port to develop an alternative runtime for the NXT? We did the RCX without this level of debugging, and the NXT is far more open. Is it necessary, nice to have, or simply not necessary at all? Given that our VM is, at (...) (17 years ago, 29-Jun-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | 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)
|
| |
| | RE: Custom firmware crashing on boot
|
|
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 (...) (17 years ago, 27-Jun-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | 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)
|
