Coldfire Lite Web Server/ Web Uploader Block Address

[dyspn]

Hello,

I have the Coldfire Lite Web Server on a custom target board with the MCF52230 on it. The problem is I need to be able to use the emg_web_uploader tool to upload a dynamic filesystem. The web_uploader tool writes to block address starting at 0x24000 and ends at 0x40000, which I believe is a problem since the MCF52230 only has 128KB of flash memory, and is writing outside of it.

Can I change where this is writing to in the Web Server code, or is it hardcoded into the web uploader and something I can't change? I was messing with things like the FLASH_START_ADDRESS, but I haven't had any success so far.

Thanks!

[TomE]

AN3455 says the download protocol has a "length" field. This has to come from somewhere. Most likely it comes from the length of the "file system file" that you've built. The size of that may be controlled by the number of files in it, or an option given to the program that built that file. Maybe you have too many files in there?

The EMG uploader is supposedly in the file "emg_https_uploader_client.c" It should refuse to accept a download larger than the size of the FLASH, Either it has the wrong size built into it, or it doesn't check. If you can't change the sending size, and know there's less real data in there than that, then you could modify the cliekt file it ignore the excess data.

> "upload a dynamic filesystem".

That's confusing. Do you mean "dynamic HTML" or do you mean a "Writable FFS Image"? The latter filesystem is "Static" in that you can't change the files.

Where did you get the "Coldfire Lite HTTP Server"? I can't find in on Freescale's site. Found it. The link in this post from 2007 still works:

https://community.freescale.com/message/28650#28650

http://www.freescale.com/webapp/sps/download/license.jsp?colCode=AN3455SW&location=null&fsrch=1

You might find this useful:

http://cache.freescale.com/files/microcontrollers/doc/train_ref_material/TCPIPSTACKOVR.pdf

This demo is very old. I'm surprised you can still build it.

Tom

[dyspn]

I'm trying to use the webserver from InterNiche’s ColdFire TCP/IP Stack|Freescale. ​Also, I looked at the pdf and decided I should try the static method. It's working perfectly on the M52233DEMO board, but again not working on my MCF52230. I'm not sure what's wrong at this point, as the static system doesn't use the write/erase functions. I looked at the packets and I can see the GET get sent out, but I never receive an OK back, and then the connection terminates. I'm not sure if it can't find the file, or if there is something wrong in how it gets processed and sent out. Still confused on what could be different between these two CPUs that's causing this.

I can ping the board, but when I try and type the IP into the browser it just hangs until the connection times out.

[TomE]

Do you have a debug pod? Time to debug that way if you do.

If not, time to drop back to 50 year old debugging techniques - start sprinking "printf()" statements through the code and stay in the edit/compile/run loop for as many days as that takes.

Tom

[dyspn]

Yeah... I don't have a way to debug it, or a way to connect it to serial to actually see any of those printf statements. Just been doing trial and error for about two days straight, and none of my changes have seemed to have done anything.

I appreciate you trying to help though. Does my CPU support MQX? Would it be easier just to make a web server with that instead?

[TomE]

> I don't have a way to debug it, or a way to connect it to serial

> custom target board

Shoot the hardware designer. Now. Unless that's you, in which this still applies.

How are you getting the code into it if you don't have a debug pod? I though that was how you programmed these things. Or is this one of the "Flash Emulation" CPUs?

Can you get to any pins that can be reprogrammed/multiplexed as a serial port? You can get 3V Serial out of that and then you wire an off-board RS-232 converter to it. You can even buy 3.3V serial level USB->RS232 pods for this purpose.

OK, so you go back to a previous era and debug by flashing a LED. How's your Morse Code? Or if you can get to any pin you can use it to bit-bang a serial stream using a software UART.

But seriously, you've got a working TCP/IP Ethernet port on that thing, so it should only take a few lines of code to connect your "printf()" statements to a basic Telnet Server. Just serve up a single port, and when connected just dump the "printf" data down it. You can connect to that using putty or "telnet ip port". If that is too hard, dump the print strings into a UDP port. You'll have to write the code to receive the data (or capture it using Wireshark).

I don't know anything about MQX. Except that for any software you want to port to anything you have to have the ability to debug it, and the higher level (source level debug pod with single-step - you know, get at least to the 1990's) the better.

Depending on which country you're in, they should have outlawed "debugging without a debugger" in 1689 or 1791. If you don't agree that it is "Cruel and Unusual", it is at least a waste of time and money that could be better spent.

http://en.wikipedia.org/wiki/Cruel_and_unusual_punishment

Tom

[dyspn]

Welp, I just tried the MQX webserver and it worked out of the box on my board. That was a bunch of hassle for nothing.

And the way I'm programming it is generating .s19 files with CodeWarrior, and then downloading them to my board by using a combination of the DEMO board, EZPORT, and STICKOS.