NE64 OpenTCP example without Serial Monitor

[nerdboy]

Hi,

I have the NE64 development board and have successfully modified the supplied Connector_app code to achieve what I need to do (simple UDP packet send). This was achieved by communicating via the serial monitor.

Now I'm using a P&E USB Multilink to try to program the same code via BDM. It seems I've wiped out the monitor program on the development board, and the code does not run correctly. I keep running into ILLEGAL_BP (breakpoints). I'm assuming that this is because the monitor isn't there anymore to jump the uController to the right _Startup location.

I don't want/need a monitor anyway, so I made a new project using the CodeWarrior wizard, which just blinks some LEDs. I was able to program this just fine and achieve the desired result. The wizard produced a rather different .PRM file which changed the memory map.

The final step: getting my old OpenTCP application to work in this new project. I included all the files from my initial application into this new project and it compiles and flashes fine. However, the code does not run correctly and the PC always ends up at some crazy address, generating an Illegal Breakpoint.

I've tried playing around with the .PRM file to get things working. The biggest problem I see is that the project wizard gave: RAM = READ_WRITE 0x0400 TO 0x1FFF;
The old .PRM file had: RAM = READ_WRITE 0x3200 TO 0x3FFE;
But if I set the RAM to the latter location, the code doesn't even seem to start at the beginning of main() and it's one illegal breakpoint after another.

I'm sure that there are some other memory placements defined outside of the .PRM file, and I'm having a hard time finding them and figuring anything out. The following two things would help me out ENORMOUSLY:

1) Finding an existing bare-bones OpenTCP application that has the memory all sorted out so that I can program it into monitor-free NE64s.
2) Learning what memory conflicts and such I have to resolve to get my existing project working.

Thanks in advance for any help! If you want to see code, just let me know.

Jeff

[DrSeuss]

I could be wrong and no longer have the s12 tools to verify, but i think the project was originally setup to have at least two targets. One was for use with serial monitor the other was BDM. Simply selecting the proper target should have done the modification above.

Did you look for two projects on the disk / website or multiple targets?

This might have changed with newer releases of the CW tools. This was released several years ago.

[mjbcswitzerland]

Hi Jeff

I'll take a guess - based on the fact that the Serial Monitor sets the SRAM to be at a fixed location (using INITRM - see the following post for details:
http://forums.freescale.com/freescale/board/message?board.id=16BITCOMM&message.id=938#M938
)

This tells me that the original code you used was set up like this - it is also not possibe to change it after it has been written once in normal mode. It sets 0x39 and the SRAM is located between 0x2000..0x3fff.

The SRAM position must correspond to the setting in your linker. It may be that the initialisation file you are now using sets the RAM somewhere else so if you want to get the origianl code (which was running with the serial monitor) to run without the serial monitor you must ensure that the initialisation code (usually one of the very first instructions) is setting the RAM to be at the same location as required by the file. (Typical in assemble file using: movb #0x39, INITRM; (RAM 0x2000 - 0x3fff))

This may help.

By the way, take also a look at the uTasker (see post
http://forums.freescale.com/freescale/board/message?board.id=16BITCOMM&message.id=897
)
It is a complete operating system with TCP/IP stack including FTP, TELNET and FLASH file system as well as a real time simulator, allowing your projects to be developed and tested on the NE64 simulator before downloading to the target. It also allows project upgrades to the M5223X by setting a compiler switch. It is free for non-commercial work and is supported here and by personal email, also free of charge. It is delivered with ready-to-run Codewarrior, IAR and GNU projects so will enable you to save lots of time.

Regards

Mark Butcher
www.mjbc.ch

(Alban linked)

Message Edited by Alban on 2006-08-30 10:26 AM

[nerdboy]

Vielen dank Mark,

After lots of playing around today, I finally got OpenTCP working and BDMed into some NE64s. Here's a recap of the things I had to modify, in case someone else runs into the same problem.

First of all, in the PRM file, you'll want to keep the RAM in the same spot as the OpenTCP default:
RAM = READ_WRITE 0x3200 TO 0x3FFE; /* BUFMAP = 4 (1.5K) */
is what I used, but any of the other BUFMAP settings should work. When I switched to BDM programming, CodeWarrior generated a PRM file with the RAM from 0x0400 to 0x1fff - that's the only reason why I was hesitant to revert.

Next, the INITRM stuff that you mentioned comes into play. In the Start12.c file, if you're using _HCS12_SERIALMON, then the following three instructions are executed:
___INITRG = 0x00; /* lock registers block to 0x0000 */
___INITRM = 0x39; /* lock Ram to end at 0x3FFF */
___INITEE = 0x09; /* lock EEPROM block to end at 0x0fff */

Since in my 'new' project, _HCS12_SERIALMON was not defined, the instructions were never run and having my RAM from 0x3200 to 0x3ffe didn't work. Having the RAM from 0x0400 to 0x1fff was fine however. I just commented out the "#if defined" bits in Start12.c to ensure that these always get executed.

Having done that, I could get the code to run, but interrupts were still buggy and the ethernet wouldn't work. The problem here was again how the project wizard set up the PRM file in conflict with the OpenTCP code. In the PRM file, I have a line that says:
VECTOR 0 _Startup
However, in Vectors.c, the _Startup vector is also defined in the interrupt table:
const tIsrFunc _vect[] @0xFF80 = {lots of stuff, _Startup};
If you try to compile, you get a linker error because _Startup is doubly defined. I guess I 'patched' this by removing Vector.c from the project. After retracing my steps, I realised that the interrupts were buggy because there was no interrupt table! So I put Vector.c back in the project and removed _Startup from it. Then the linker was happy and everything finally worked.

Alternatively, I imagine you could scrap the VECTOR 0 _Startup from the PRM file and leave Vectors.c as it was, but I haven't tested that.

The moral of the story: "the transition from serial monitor programming to BDM programming would have been much easier had the OpenTCP paradigm and project wizard paradigm been congruent". Or "if I knew what I was doing, this probably wouldn't have been so bad".

Thanks again for the help, and hope this info helps others...

Jeff

[mjbcswitzerland]

Hi Jeff

Good stuff.
There is one other point which may be worth a mention here.
The NE64 requires the Ethernet buffers to be set at the start of SRAM. These can be programmed to have various sizes, starting at 128 up to 1,5k each.
This means that the linker must actually know where the Ethernet buffers end and not where the SRAM begins since it should not put any variable in the Ethernet buffer space (otherwise they will be corrupted by Ethernet frames).
Now I don't know how to automate this since it is the program code defining the Ethernet buffer space and the linker doesn't (normally) know such details.

I'll give an example. If you have a project were only small Ethernet frames are to be sent and received it is possible (practical) to use 512 or even 256 byte Ethernet buffers. In the case of 512 byte buffers (2 x rx and 1 x tx) and assuming SRAM is located between 0x2000 and 0x3fff, the linker file should be set to use 0x2600..0x3fff (0x2000..0x25ff reserved for Ethernet use).

Since the user's code can control how much of the tx buffer is really required (he/she can't control the rx buffer use) - eg. he/she knows that the largest frame will be 128 bytes - it is possible to actually set the linker SRAM range to 0x2480..0x3fff.

I find 512 bytes works quite well for small web servers etc., allowing a good compromise between Ethernet buffer space and application SRAM use - however there is a complication when using DHCP. DHCP requires the ability to receive frames of up to 576 bytes. Now this forces the use of 1k buffer space - just for a potentially longish DHCP frame!! and the application looses at least 1k SRAM....Often the user can configure to use fixed IP addresses or DHCP (see online demo at http://212.254.22.36/ - in the LAN configuration side) and this buffer space has to be reserved for this, although often DHCP is not even activated. Normally it's not a big deal but one has to be careful with the 8k available in the NE64 and throwing 1k (at least 13%) away can cause restrictions elsewhere.
My quote "DHCP is no friend to the NE64".

By the way, I have a DHCP document at
http://www.mjbc.ch/documents/uTasker/uTaskerDHCP.PDF
where I have discussed a little such memory use. I also once evaluated the OpenTCP DHCP support. It does in fact deviate on quite a number of points from the RFC 2131 (I don't remember exact details but it has no randomisation - which is a MUST according to the RFC - and I doubt that it supports really long lease times; theoretically up to about 100 years [which I did actually test in the uTasker version... although speeded up slightly...]).

Cheers

Mark