Latest uTasker code for M522XX with GNU compilation

[frank]

Hi Mark,

What is the latest uTasker code for M522XX processor ?. Can you please let me know your recommended GNU tool chain as well ?. I am not planning to use Code Warrior.

Thanks

[mark]

Hi Frank

The latest code is available here: http://www.utasker.com/forum/index.php?topic=1310.0 (it always supports GNU).

CodeSourcery was the standard source of the compiler (Coldfire and ARM and variosu others) - this company was bought by Mentor Graphics a while back but they still offer the Lite edition of their (Eclipse based) development environment which is a Windows installer (maybe othere OSs too) for the GCC tool chain.
Try http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

Regards

Mark

[frank]

Hi Mark,

I tried with the latest uTasker code on my custom board ( based on MCF52232 with STM25P16 SPI flash). I couldn't get the  uTasker working in my board.

Not sure where to start..

[mark]

Hi Frank

I would try first on a standard board to verify that the build is OK.

It is also advisable to run the code in the simulator to check all configurations when moving to your custom board.

GDB can be used for debugging but this can be a bit tricky unless used as part of a package.

I would recommend loading the GCC derived code to the board (make sure that it is correctly loaded to the FLASH) and connect to it using Codewarrior (I still prefer the CW7 special edition for doing this) and check that the code in FLASH matches the binary file that was generated. Then check that the SP is loaded with the expected value and the code steps in assembler. Using the addresses from the GCC map file you can also put breakpoints at the routines that are expect to be called to see whether it hangs somewhere before reaching them.

With a bit of practice code in the routiens can also be debugged in assembler (although not very comfortable).

If there is a crash it is usally possible to home on in where it is taking place and hopefully identify why.

Regards

Mark

[frank]

Hi Mark,

I have tried the latest code ( v1.4.11) with the CodeWarrior.  I am able to bring-up the application in the following scenario.

1. Bootloader, built using uTasker v1.4.0

2. BareMinimum image built using uTasker v1.4.0.

3. Upgraded application, built using uTasker 1.4.11.

After the new image is up and ready, FTP and Webinterface didn't work.

In FTP case, i can login the device, but failed to execute "dir" command. Also, not able PUT any files.
In webserver, nothing works ( since not able to upload any files via FTP ).

so, in a nutshell, I can upgrade the image  ( which is built using v1.4.11) from the earlier version of the uTasker image ( built using v1.4.0). The bootloader was built using v1..4.0.  ( in fact I don't want replace the existing bootloader).

Running the latest uTasker via Simulator works fine with FTP and webserver files. So, time being, I would like to solve the CodeWarrior problem, then move onto GNU.

In the configuration side, both FLASH_FILE_SYSTEM and SPI_FILE_SYSTEM are enabled in addition with SPI_FLASH_STM25P16. The relevant flags which points MCF52232 also enabled.

Please note that uTasker v1.4.0 works fine in all the cases ( ftp, web, upgrade etc ).

[mark]

Hi

Have you checked the following CW7.1-2 bug workaround? http://www.utasker.com/forum/index.php?topic=1272.0

Regards

Mark

[frank]

Hi Mark,

I tried with the workournd, but no luck. I am using Codewarrior 7.2.  I don't have any problem with uTasker v1.4.0 ( haven't tried the other versions ).

- Franklin

[frank]

Few more updates on this topic.

1. I have tried with CW 7.1, the behaviour is same. i.e, the filesystem from external SPI flash(M25P16) doesn't work. I can't execute "dir" command in FTP. It hangs. Not able to upload any files.

2. FTP works with internal flash memory ( by disabing SPI_FILE_SYSTEM). But, when I upload(ftp) more than 2K file size ( 3594 bytes) , I can get back only 2k bytes. Files below the size of 2920 bytes can be retrieved safely.

3. During the filesystem testing on internal memory, I have left 24K size for filesystem in the internal memory.

4. Both CW 7.1 and 7.2 works same when the filesystem is tested on external spi flash..


Everything working perfectly fine on uTasker 1.4.0 ( even it is compiled on CW 7.2 ).

[mark]

Hi Frank

Please check that you have applied any known patches (see below the V1.4.11 version release notes here: http://www.utasker.com/forum/index.php?topic=1310.0 ).

If there is nothing there that helps, please send me the following files from your project:
- config.h
- app_hw_m5223x.h

Also please confirm the target and linker script file used in the CW7 project (is it a standalong target or one working with a boot loader?).

I will then check the same configuration on the same/closest board that I have.

A couple of other points/questions:
- have you tested with the simulator? Are results the same or does it work there?
- it may be interesting to also send me a Wireshark recording of the FTP transfer(s) that show problems. This often helps to identify which operations need to be looked at and also useful for comparisons when I do the same tests.

Regards

Mark

[frank]

Hi Mark,

Please find attached the header files config.h ,app_hw_m5223x.h and the linker file. The target is 52232 with STM25P16 SPI flash.

I haven't taken the patch code for TCP and fnEraseFlashSector(). I will try with this patch ( I am not using IPV6, so TCP patch may not be relevant ).  Let me try with the patch and post you the status.

I also tried with simulator, but did't see any problems. Both FTP and webserver works.

Thanks.

[frank]

I have attached the pcap file which was captured when the "dir" command was issued after logging-in FTP. 192.168.15.109 is the device IP address.

[mark]

Hi Frank

I took a first quick look at this and it looks as though the board is resetting when you request a DIR (presumably with SPI flash) - it looks to stop responding when the listing shoudl be returned. Could you check that the SPI Flash is being recognised - fnCheckSTM25Pxxx() in spi_flash_m5223x_stmicro.h. If this is failing (eg. CS line is not correct) the SPI interface will be powered down and so no access possible (without an exception taking place).

Without SPI Flash I didn't see anything wrong with the configuration. You look to have 24k of file system space internally. In the simulator it does seem fine. Could you check the program size that is being generated to ensure that there is no overlap of code and file system? The new version possibly has a lot more enabled by default and so need more space. Also check the stack space.

Regards

Mark

[frank]

Hi Mark,

I don't see the board gets reset, because after CTRL+C, the board is still reachable. Let me check whether SPI is detected or not ?,.

[frank]

Hi Mark,

The problem is fixed.

As you said, CS line was set to wrong bit of PORT_QS. In the earlier version of the code ( uTasker v1.4.0), CS0_LINE was mapped against PORT_QS_BIT3, but it has been changed to PORT_QS_BIT5.

Thanks for your support.

Cheers