Problem uploading new firmware.

[phomann]

Hi Mark,

I'm having trouble uploading new firmware via the admin web page. It used to work, so I'm wondering if I hit a limit somewhere?

I'm using the internal flash and don't have any external Flash.


I've changed;

 the resolution of the file resolution from 1K to 2K 

The types MAX_FILE_LENGTH and MAX_FILE_SYSTEM_OFFSET are unsigned long

UTASKER_APP_START  from 0x800 to 0x1000

UPLOAD_FILE_LOCATION from 0x28400 to 0x2b000  This corresponds with file 'a' location in a 2K block file system


The #define UTASK_APP_LENGTH is left at (MAX_FILE_LENGTH)(94 * 1024)  Is this an issue.

The size of my application a_Upload.bin  is 83kb


When I try to upluad the file via the web page I get the message 'Sorry but upload has failed.'

But, if I use ftp to upload the file and then press reset, the new application is programmed by the boot loader and it works correctly.

I'm presuming that the file is not being uploaded via the web page due to some limitation that is being checked.

Any idea as to what that may be?

[mark]

Hi Peter

If the upload works using FTP the settings are probably correct.
HTTP Post is however a bit special since the destination is not controlled by the file name but by the HTTP content.

<form action=zS.bin enctype="multipart/form-data" method="post">

Here the upload location is being set to 'z' and the standard return page is 'S'.
If you change this to aS.bin it will save the posted data to a file at this location (as FTP does, controlled by the file name).

I presume that 'z' is outside of the file system (or there is not enough space for the file) and so it was failing.

Regards

Mark

[phomann]

Hi Mark,

Sorry, I missed your reply.

Yes, I had already changed the HTM file to;

   <form action=aS.bin enctype="multipart/form-data" method="post">

Funny thing is that it used to work. I have been playing around with webInterface.c as I'm saving text to a file that is entered via a testarea web object using post.

Is it possible that I've interfered with the post  processing of the firmware file?

Cheers,

Peter.

[mark]

Hi Peter

You can test the upload in the simulator.

When it fails it is because it didn't write anything to FLASH (or because the application refused the upload on connection). Due to the nature of the POST method the upload is not interrupted but still accepted but the data is not saved. At the end the error message is generated since no writes were performed.

If you set a break point in HTTP where it detects the POST you can then step through the code to see what happens - it will ask the application whether it wants to accept it (I think) and the checks the data type. Once found it will start with saving the content.

If the data type is not supported it will also not save it. You should be able to see what it actually handles the first TCP frame since it will contain the HTTP header followed by some data. You should be able to see why it is being rejected.

Regards

Mark

[phomann]

Hi Mark,

I have used the simulator as you suggested and it is rejecting the data. basically, when it gets to the line( around 750) in http.c ;

Code: [Select]

if (EXPECTING_DATA & header_search_state.ucState)
It fails because header_search_state.ucState is 0x67 and EXPECTING_DATA is 0x02

By looking at the state machine and breaking on the switch statement, the states appear to go;

switch state  (ucEvent         header_search_state.ucState
-------------------------------------------------------------------------       
BOUNDARY_FOUND                              0x03
CONTENT_LENGTH_FOUND                  0x41
FIRST_BOUNDARY_FOUND                   0x45
CONTENT_TYPE_FOUND                      0x65
FIRST_BOUNDARY_FOUND                   0x67
-------------------------------------------------------------------------       


fnHandleWeb(CAN_POST_BEGIN, 0, http_session) is then called and returns 0
The line

Code: [Select]

if (EXPECTING_DATA & header_search_state.ucState) is then executed. It is false so the line

Code: [Select]

http_session->ucState = HTTP_STATE_DUMPING_DATA; is executed and the file is not stored.

Does the above give an insight into why it is failing?


Cheers,

Peter.

[phomann]

Hi Mark,

I found the problem.

I had installed a compression file called Stuffit. It changed the .bin file application type to 'Stuffit'. Therefore the firmware file was rejected as the applicationtype sent to utasker was stuffit.

It's great the way some companies decide that their application is so important that they have the right to change application types. NOT.


It does identify an problem that could occur with my customers. I'm thinking of changing the file extension of my firmware upgrade files to something unique.

Not sure how to find a unique 3 character extension though. Maybe there is a register or list some where.

Cheers,

Peter.