Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jamier

Pages: [1]
FreescaleTM MC9S12NE64 / uTasker IIC
« on: July 25, 2008, 05:42:05 AM »
Hi Mark,

I am having some trouble communicating to a custom device using IIC.  uTasker was set to slave but I couldn't receive anything but I could set uTasker to master and transmit ok.

After reading the docs I realized that receiving in slave mode is not supported. 

Is there an update that can provide general purpose master/slave read/write functionality?



FreescaleTM MC9S12NE64 / Re: Using uTasker 1.3with Multilink BDM
« on: July 25, 2008, 05:32:47 AM »
Hi Fabricio,

I use the BMD with CW too and as I recall Mark is correct in that there is nothing to change in configuration (config.h). 

But you might want to change your linker a bit.  For example the original linker file has this line:

ROM_C000 = READ_ONLY  0xC000 TO 0xF7FF;

The address 0xF7FF leaves some room for the serial monitor.  If you need the space for one reason or another, you can change it to 0xFEFF.  This frees up some FLASH, but still leaves the last 256 bytes for vectors and reserve registers for FLASH.  If you plan to reload the serial monitor at a later time it might be better to create a separate target so you can leave the serial monitor linker as is and create a new linker file for the new target.

It's a minor thing, but it puzzled me for a bit since I need to make use of that space and it didn't work until I figured the linker reserved room for the serial monitor.


FreescaleTM MC9S12NE64 / Re: Global Hardware Timer
« on: May 22, 2008, 05:04:34 AM »
Hi Mark

I think for me the easiest thing to do is try the regular SW timer.  I changed the tick to 10ms and used uTaskerMonoTimer.

This seems to work ok. 



FreescaleTM MC9S12NE64 / Re: Global Hardware Timer
« on: May 21, 2008, 05:32:49 AM »
Hi Mark,

I tried your quick fix for a 10ms Global HW timer - it does work (though it was running at 20ms with the values you gave but I think it was probably something I was doing wrong)

Does the HW timer interrupt interface support other timers?  The Global HW timer is set up by default to use timer 7 but our hardware uses PT7 to generate a waveform using output compare.  I am not sure yet but I would expect a conflict. 

So it might be easier to set up a different timer for my 10ms timeout using the HW timer interrupt interface.



FreescaleTM MC9S12NE64 / Global Hardware Timer
« on: May 12, 2008, 01:44:06 AM »
Hi Mark,

I am trying to set up the global hardware timers for a 10ms timeout.

After playing around a bit, and checking the docs I notice that the define for MILLISEC doesn't appear to exist in the NE64 project.

When I try to set the timeout using:


The timer triggers only once - the delay value ends up being set to 0. ( The uTasker tick is set to the default of 34ms.)

I suspect that a correct define for the MILLISEC would fix the problem - has this value been determined for the NE64?



FreescaleTM MC9S12NE64 / Re: Ethernet Buffers
« on: May 12, 2008, 01:37:59 AM »
Hi, Mark.

I see now that the chips EMAC expects those two buffers to exist.

Thanks for tip on using some of the RAM normally reserved for the TX buffer - that may work.


FreescaleTM MC9S12NE64 / Ethernet Buffers
« on: May 09, 2008, 08:34:36 AM »
Hi Mark,

Is it possible to use only one Ethernet RX buffer?

By default uTasker has 2 RX and 1 TX buffer for a total of 3k.

We can't really decrease the size of the buffers since we are using DHCP so the only possible option that I can see is to eliminate one RX buffer.

Any other suggestions for reducing RAM? - so far I've looked through config.h and modified a few things.  I am also looking at the application RAM use to see if we can sacrifice a few things there too.



FreescaleTM MC9S12NE64 / Lowest System Tick?
« on: February 29, 2008, 03:31:13 AM »
Hi Mark,

I see the tick resolution in v1.3 is set to 34ms.

Is there a minimum that you would recommend?  It looks like the RTI can go as low at 41us.

We have some time constraints on a scale of 10ms.  It would be nice if we could handle these within a uTasker task.



FreescaleTM MC9S12NE64 / Re: Bootloader on NE64
« on: February 20, 2008, 07:15:52 AM »

Thanks for the explanation and feedback.

Regarding your uTaskerConverter tool...  will it be of use to me in converting my .s19 for an NE64 application to a usable binary file for my custom bootloader?  Is there any documentation that goes with the tool?



µTasker general / Filename convention documentation incorrect?
« on: February 18, 2008, 08:10:03 AM »
Hi Mark,

I noticed while trying out TFTP upload that it appears the filenames beginning with uppercase letters came before file with names beginning with lowercase letters.

This contradicts the what is stated in the document which says "The file locations count from ‘0’ to ‘9’, and then from ‘a’ to ‘z’, then from ‘A’ to ‘Z’."

From this description I would expect 'a' to follow '9' but it seemed that 'A' followed '9' with my testing... actually the problem manifested when i tried to upload a ~48k file named 'gfake.bin' and TFTP would always throw an error because there wasn't enough disk space.  When I renamed the file to "Gfake.bin" the upload could proceed to completion.

I am using uTasker v1.3 SP1 for NE64 but this doesn't seem to be a hardware specific issue.


FreescaleTM MC9S12NE64 / Re: Bootloader on NE64
« on: February 16, 2008, 10:42:29 PM »
Hi Mark,

I am having lots of fun playing with uTasker and it various capabilities!  I find as I go I am learning a lot and correcting some misunderstandings I have been harbouring since starting my evaluation.

One particular misunderstanding I have had, I think, is regarding the file system and application.

Correct me if I am wrong, but the application does not live in the file system, does it?

I think my task creating a bootloader for NE64 is now simplified.

In config.h, I can define SPI_FILE_SYSTEM and not define FLASH_FILE_SYSTEM.  That way files uploaded to the NE64 get written to a 64K external SPI EEPROM while the application still runs out of internal FLASH as usual.  The drawback is the 16k reserved for internal file system is not available for files.  (But I suppose it frees up 16k for application code, correct?)  Reading the documentation again seems to state this quite clearly - I am not sure how I missed it!

So ignoring the complications with interrupts as we discussed previously, would it not be possible to have the firmware upgrade process work as follows (using the releases code for NE64 uTasker SP1):

1. Start with programming via BDM the blank NE64 FLASH with the applicatin - EEPROM is blank.
2. Run the application, connect with TFTP (rather than FTP since TFTP takes dramatically less resources).
3. uTasker receives webpage files and stores them to SPI EEPROM.
4. Webpages are now active and can be browsed.
5. Some time later, we want to do a firmware upgrade.
6. Connect via TFTP and transfer a new application file.  The file gets written to the file system on EEPROM, as usual.
7. Reboot.  (What follows will be standard boot process regardless of firmware upgrade or not)
8. Bootloader, which I've developed, checks the EEPROM for a valid application which has been predefined to start at a certain address.  If found, copy the file to internal FLASH.  If not found, jump to application in FLASH.  The application in EEPROM can be erased by the bootloader, or by the application at startup.
9. User reconnects via TFTP and transfers new webpages, if required.  (If new applicaiton is less than 48k, webpages stored in EEPROM remain intact. so no webpage transfer is required)

6a. Alternative to step 6.  Rather than TFTP, a webpage can provide this functionality, as long as application is less than 48k so that webpages do not have to be erased.

Does this seem like the best approach, after the other scenarios that we've discussed?

Your comments are greatly appreciated!


FreescaleTM MC9S12NE64 / Re: TFTP with uTasker v1.3 SP1
« on: February 16, 2008, 08:44:38 AM »
Hi Mark,

I was able to get TFTP to transfer a file to the PC when I enabled the TEST_TFTP using the simulator.  Thanks. 

However, I could not send a file to the NE64 until I made two changes in the code:

1. In file tftp.c, function fnGetFileMode(), I had to change !uStrEquiv(cOctet, Data) to uStrEquiv(cOctet, Data).  The code is looking for a match in the TFTP transfer mode and the logic was reversed.  Once I made the change, I could get a bit further so that TFTP transfer could be initiated.

2. In file tftp.c, function fnTFTPListner(), the line:
               else if (!(ucTFTP_state & TFTP_STATE_CLIENT) && (!uMemcpy(ucIP, cucBroadcast, IPV4_LENGTH))) {

         had to be changed to :

               else if (!(ucTFTP_state & TFTP_STATE_CLIENT) && (!uMemcmp(ucIP, cucBroadcast, IPV4_LENGTH))) {

It lookse like the original call to uMemcpy should have been Memcmp.  The comment was "// server not allowed to accept a broadcast address" so it seems you would want to do a mem compare rather than a mem copy.

Once I made those changes I could send a file and verify it was recieved by connecting via FTP and getting a directory listing. Are these correct changes?

Now that I see TFTP working, I am a bit unclear on how one would enable this for application use.  The define for TEST_TFTP suggests that this is only used for testing the TFTP functionality.

For application use, would one simply call fnStartTFTP_client() at start up (or maybe at some user initiated prompt during runtime) to activate the TFTP functionality?

Also, there would probably have to be some way to set and save the TFTP server IP at runtime as hard coding it at compile time would likely impose an unacceptable constraint for most applications.  This should be simple enough for me to do via a webpage.


FreescaleTM MC9S12NE64 / Bootloader on NE64
« on: February 14, 2008, 06:20:24 AM »
Hi Mark,

From our email correspondence you may recall that I am required to implement a bootloader on the NE64.  I wanted to bring this discussion here for the benefit of other users.

Here is a summary of what I am trying to achieve - at the end I'll have a couple questions that will help solidify my plans.

Since the application is expected to exceed 32k, I have been provided with a SPI EEPROM (25AA512) for external storage - not the ideal case in the uTasker environment.

What I would like to do is receive an application .bin file over FTP and rather than writing to the internal file system, write the data to the EEPROM in chunks as each piece of the file is received.  Once written to EEPROM, the application would validate the application image (in EEPROM) and if all is well, reboot.

Upon reset, the bootloader runs first and checks the EEPROM for an application.  If one is found, the bootloader will erase the application stored in FLASH and copy the new application from EEPROM to FLASH.  If the copy was successful and the application in FLASH is valid, the EEPROM is erased and the device reboots.  New application runs.

The real challenge, I think, is modifying uTasker to direct the received application .bin file to EEPROM rather than the internal file system.

Mark, is my proposal possible?  Would you recommend a different way?

I know your next SP for uTasker NE64 has greater functionality for external file system support, but in my case with the EEPROM I have been given, I don't think it will help me much - is this correct?



FreescaleTM MC9S12NE64 / TFTP with uTasker v1.3 SP1
« on: February 12, 2008, 07:11:27 AM »

I tried to send and receive a file via TFTP without success. 

I think I am missing something important... I have no problem with FTP.

Perhaps TFTP is not intended for general file transfers - maybe only in a bootloader?

My target board is custom hardware with the NE64 micro.  I have TCP/IP connectivity - FTP, DHCP, HTTP are all working.

Any suggestions?



Pages: [1]