bare min app link errors

[johnr]

 Hi, I'm using the CW 6.3 light version and I see 2 projects in the list box on in the upper
left corner of the IDE when I open uTakserV1.3.mcp,  M52235EVB_ROM and bare_min_app_rom. I can build and run M52235EVB_ROM with no problem. When I select bar_min_app_rom I get the following link errors :

 Undefined  "main"  from start in startup.s
 Undefined  "mcf52235_init"  from start in startup.s


 I read through the docs but can't see anything I have to set.
 Any ideas ?

 Thanks,
 John

[mark]

Hi John

This is strange because the V1.3 SP5 reference I have doesn't have this problem.
However it does look as though somehow the file \hardware\M5223X\M5223X.c (which contains main) has been removed from the project build.

Check:
- when you select the bare_min_app_rom build that M5223x.c appears in the virtual hardware directory. If not, add it [click on the virtual hardware folder, right click mouse, Add Files.., find the file in  \hardware\M5223X\ and add it].
- If the file is there, check whether it has been compiled. It should display code and data size of about 9416 / 466 respectively. If it displays n/a it has been disactivated from the project (this can be done by double clicking in the next column which has a sort of arrow to a red target as caption) - if this is the reason, double click the column to reactivate it again. It will return with sizes 0 / 0 so simply recompile and then all should be fine.

Perhaps you double-clicked the deactivate field once by mistake, or else the project file has been corrupted in some way (?).

Hope you can solve it quickly.

Regards

Mark

PS. Note that to use this build you will also need the bootloader project - see the document http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF for full details.

[johnr]

Thanks Mark, I deleted M5223x.c from the project then added it back and it compiled OK
It was inadvertently set to  N/A code and data size. I'm still learning CW
 I built the boot loader project and flashed it in, erasing from 0x0 - 0x7ff. I then built the uTasker-BM project and flashed it in, erasing the flash from 0x800 to 0x17fff to preserve the boot loader, params and file system.
 I was able to boot up and the saved params were intact. I then tested the SW upload
by changing the version in config.h to V1.3 006, compiling and then running BM-convert.bat. The H-upload.bin was 78K. I uploaded it from the web and everything looked OK and it reset within 10 secs. When I refreshed the main screen the Version display was V1.3 000. Also the Device ID defaulted to "uTasker Number 1", not what I set
it. The LAN configs looked ok but the serial baud defaulted to 19.2K.

 When I flashed in the same BM code from CW and reset, the version then displayed properly V1.3 006, the value I set in config.h

 Thanks,
 John

[mark]

Hi John

Your methods look good - I also change the SW version when testing to check easily that the new one is really running.

I can't explain why the SW version displayed V1.3 000 after the upload and not V1.3 006 - the version number is a hard coded string so it would suggest that the SW you uploaded was not that which you expected.

One reason why parameters can be reset to defaults is when the version number parameter list (entry ucParVersion) doesn't match with the version in FLASH. In this case the parameter system will be deleted and the board works with defaults again (19'600 is default baud for example).

Therefore the only logical explanation that I have at the moment is that you converted and uploaded a version V1.3 000 which may have been present in the directory rather than the new one you had created. This would probably have had a different parameter version and so also caused the 'invalid' parameters to be deleted (this is done to avoid using a structure which is no longer compatible which can otherwise have strange consequences).

Note that you will be able to clearly see that the new version was really programmed because after the reset (after upload) there will be a period of about 3s when the LED doesn't blink. This is the time taken to delete the previous SW, program the new one and delete the backup of the old one.
It is also simple to see when an upload was not accepted due to the new SW having incorrect header  - in this case there is no pause after the reset and the uploaded file will be visible in the file system (via FTP) rather than being deleted once it has been successfully copied.

I don't know of any problems with the boot loader - set ups for internal FLASH and also recently external SPI FLASH have been shipped in products by some users so I am still assuming that this must be a local problem during your tests.
Perhaps you could try a few more times checking carefully the location, time and data of each file to be sure that the correct ones are used. It should be possible to change the version number and not affect the parameter system in the process.

I hope that you have success.

Regards

Mark

[johnr]

Thanks Mark, it was user error I have 2 copies of uTasker on my PC. The "live"
one runs under VMware, which I want to use for my development work because it's
easily backed up and restored. I initially had problems using USB under VMware so I
installed the development environment on the real drive for testing. Now that it's working
under VMware, I'll delete it to avoid confusion. My main web browser runs on the real drive
so I was uploading an out of date file by mistake !
 Everything looks OK now !


 Thanks,
 John

[mark]

Hi John

I am glad that could be explained.
Good to hear that things are now working as hoped.

Regards

Mark