Author Topic: Solving problem with the uTasker "Bare-Minimum" Boot loader using the utasker si  (Read 4135 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3147
    • View Profile
    • uTasker
Hi All

A common problem when starting with the "Bare-minimum" boot loader is that the upload works but the new code is not programmed. This happens when the configuration of the boot loader doesn't match the configuration of the upload file, but finding exactly what is not matching can sometimes be a bit of a challenge - the boot loader configuration may not automatically match the chip being used or the file system being used in a project and some adjustments may be required.

Note that a good indication of mismatch between boot loader and upload file generally results in the upload working but the boot software starting the old application immediately. This is because it sees that there is new code available but ignores it since it is not valid for its configuration. When the application runs it is possible to see this uploaded code in the file system (eg. by performing an FTP DIR). After a successful upload the boot loader will otherwise delete the upload image.

Using the uTasker simulator allows for comfortable testing of the upload sequence, allowing any problems to be quickly identified, corrected and verified. The following guide is a step-by-step on how this can be performed:

1) Run the uTaskerV1.4 application in the uTasker simulator. Make sure that the web pages are loaded and that the upload form is ready on the "Admin" web side.

2) Compile a new application (cross compile for real target) and convert it ready for an upload (using uTaskerConvert.exe). This will be a file called H_upload.bin or similar.

3) On the Admin web page perform an upload of this file. It will take about 1s to upload and a web page should appear confirming that all went well, after which the simulator will display a reset window. This means that the simulator has detected a commanded reset and will terminate - click OK.

4) In the simulator directory the content of memory (including the newly uploaded software file) will have been saved in the file FLASH_M5223X.ini (name depends on the processor being simulated). This is the internal FLASH content. If working with the file system in external memory (or partly in external memory) there will also be another file called something like AT45DBXXX.ini (the name depends on the device being used). These can also be opened in a binary editor to check the content and the position of data in the memory.

5) Copy this/these file(s) from the uTaskerV1.4 simulation directory to the uTaskerBoot simulation directory. Make sure that there is a break point set at the start of the routine uTaskerBoot() in uTaskerBootLoader.c and start the simulator.

6) The simulator will immediately stop at the break point and the code can be stepped through. It will enter the routine fnCheckNewCode() where the length of the SW file will be collected using the call "uGetFileLength(UPLOAD_FILE_LOCATION)". Step into the function and check that the value of UPLOAD_FILE_LOCATION corresponds to the address where the uploaded file is expected to be. Note that the simulator has loaded the memory as saved by the application and so is now working with the uploaded data from step 3.

7) Also the upload header will be fetched with "fnGetPars(UPLOAD_FILE_LOCATION + FILE_HEADER, (unsigned char*)file_header, SIZE_OF_UPLOAD_HEADER)". By displaying the struct file_header the upload header can be check against that which is expected (check for example that the magic number matches the one expected from the conversion utility parameters used to generate the upload file).

8 ) Step further to see whether any parameters don't match with local settings: the magic number accepted; the maximum code length accepted; finally the checksum calculated over the code can be verified "return (usCRC == file_header->usCRC)". If something doesn't match it should be quite easy to see what it is; the boot project and conversion parameters (application start address, encryption mode, magic number, secret key, etc.) must match between boot project and application upload file.

Using this technique it is usually quite easy to identify mismatches and then confirm the corrections so that it will work correctly on the target at the next attempt.

Good luck

Regards

Mark




Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3147
    • View Profile
    • uTasker
Hi All

Please note that there is a video guide that shows this procedure here: http://youtu.be/e7JvWodljlc

It is shown on an AVR32 (EVK1100) using SPI Flash but the procedure is the same for any storage medium and processor.

The video is quite long but may be useful in case of configuration difficulties ;-)

Regards

Mark