Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: Managing LCF files after a CW 10.2 import

« on: March 07, 2014, 06:01:19 PM »

Mark,

Thank you.  I finally got everything to work.  I tried to follow your example, but you were using version 10.3 and I was using 10.2.
I attempted to get a version of 10.3, but could only get the trial version which disables the classic import tool.  I then attempted to
move to 10.5 and import.  Sadly, the 10.5 version no longer supports the CW7.2.2 tool set so that did not work either.

Next, I once again created the 10.2 version and made sure and made sure everything was pointing correctly as you describe.  At this
point I was able to get the flash device (Multilink Universal) to load correctly but it would not debug.

Finally, I took the 10.2 version I had created and imported it into the 10.5 version.  After a few more path corrections, etc. (I am also
having an issue with not being able to use linked file paths so all are full paths...), it now loads correctly and debugs fine.  All seems good
at this point.

On more minor question: I get warnings on the .lcf file I use where you include startup.s and flash_config.s and it can't find these files (though
the project does find and use it correctly) and assumes I should have placed the .obj versions there instead.  Thoughts?  Does not really seem
to be an issue.

In any case thanks for all your help while I had the 1 year support as well as now.

                                                                                      - jon

2

NXP^TM M522XX, KINETIS and i.MX RT / Managing LCF files after a CW 10.2 import

« on: March 06, 2014, 12:15:31 AM »

So I am attempting to move my MCF53325 project from CW 7.2 to 10.2.  After performing the import as described in another
forum (http://www.utasker.com/forum/index.php?topic=1310.0) and documents on the uTasker site and making a few (OK,
many) adjustments to paths, etc. I have gotten everything to compile/link and load, but I then realized had made a mistake
in which .LCF file I was using in the project. 

The project I had compiled for the ColfFire main uTasker was intended (memory-wise) to be part of a 'full' system that includes
both of the uTasker boot loaders.  Thus I used the M52235_BOOT_APP_FLASH_SPI.LCF file where the start location of the
main application code is well past 0x00000000 (0x00004000).  When I realized this I changed the .LCF to the correct one
(M52235_FLASH.LCF) which starts at 0x00000000.

After this change, I spent the last 3 hours attempting to get the project to actually use this new starting address when it
actually flashes the ColdFire.  I have changed all .LCF file references to the correct one and the flash tool still erases starting at 0x000040000
and then proceeds to flash the MCU starting there.

So what am I missing.  I have looked through all the various settings and they all seem correct...at least the ones I looked at.

Does anyone (Mark?) know where I might find this and change it.  I believe this should be easy, but as of yet, this is NOT
the case.

Thanks much.

                                                     - jon

3

µTasker general / Re: Is it possible to update values on a Web Page without loading the entire page?

« on: October 07, 2011, 07:40:05 PM »

Folks,

One thing I forgot was the page itself.  Here is an idea of how it can be done and will work with what I described in the previous post:

<script language="javascript">window.parent.handleResponse(error indication or other flag/value here,"PagNameHere","data vales to process here")</script>

That is the entire page.  The returned indicator is optional.  The page name in this page allows for the base page to have a script to handle say all base pages and populate accordingly.  Please understand that the only real important thing here is that the returned hidden page script here must call the parent for the proper processing to occur.

Once again hope this is useful.

Take care.

                                               - jon 

4

µTasker general / Re: Is it possible to update values on a Web Page without loading the entire page?

« on: October 07, 2011, 07:17:04 PM »

Folks,

Ok, this is an old topic but as the server I wrote for the NE64 about 4 years ago does as has been described in this topic, I figured I would describe how it is down...obviously without and Ajax, et al processing.  If I repeat something from this topic here, I apologize.

Specifically, one can place more than one page in a page's HTML.  For the purpose here, the second complete page is placed at the bottom something like this:

</form>
<form name="Comm" method="get" target="Comm">
<input type="hidden" value="0" name="Start1">
</form></body>
</html>

Now as one can see, it is hidden.  So my server and pages perform a constant heartbeat to our device to make sure to the page that the server is still there.  On the server side, this allows the server to close the session if the heartbeat is not received. 

The is also used so that we never refresh any page after it has been presented.  I did not have enough RAM space on the NE64 for the largest IP packet possible so the page presentation was slow.  The background updates are fast though since the page is not refreshed and the only stuff passed back/forth is thr request as usual and then just the data change for the response.

Each page has a script to handle the hidden page response, which basically calls the same script that processes the page's original data values and updates the form.  Also some of the pages actually do not populate any fields from the base page's HTML but rather call the hidden page to send the data to populate the primary page with.  This model speeds up the presentation as my server does not handle dual-sends per browser ACK or parallel connections/requests as uTasker does very nicely.

The server just knows how to handle this special page by its name/action set.  It does the processing/data update and sends back the hidden page.

That's it.

Of course it is the responsibility of the server to handle all this in the fashion desired.  One other item helped in that the primary origin page name is included in the request made for the hidden page so that the server knows what to do for that page.  Otherwise, all of the page processing on my server is handled by the same code.

In any case, I am in the process of implementing this in uTasker v1.4 and will let you know.  As far as I can see, it should work as long as I can inhibit any std processing that might get in the way.  At this point i have not seen any, but I have not gone super deep into this.

To all, take care.

                                                  - jon 

5

µTasker general / Re: How would I place the entire uTasker file system on the 4th SPI chip only

« on: October 07, 2011, 05:02:50 PM »

Mark,

No, they are both set.  I am not sure as I said why, but the loss I see is actually on the call to fnGetParsFile.  The value of the start address passed using the pointer is correct in the calling routine uGetFileLength and once I step into fnGetParsFile, the value changes to zero and remains that way. 

Now I know this is actually a virtual pointer, but VS (and I assume any c/c++ compiler) thinks it is a 'real' pointer.  Would it be safer to pass a pointer to this virtual pointer as you do elsewhere (though as with dbl pointers, you can change the pointer's pointer as I believe you do where you use this...) and de-reference it for use?

I guess I do not see this as an issue with the settings but possible how these virtual ptrs are resolved via the linker, etc. which was why I was thinking a setting like for optimization was incorrect.

In any case, I can work with the static chip select as this is actually what I am doing (I really do NOT want to make which chip is the file system user-configurable).  I can easily use the various defines already in place to set this static select value.  Everything else in the file process on both the simulator and the Coldfire seem to work just as expected.

Thanks again.

                                         - jon 

6

µTasker general / Re: How would I place the entire uTasker file system on the 4th SPI chip only

« on: October 06, 2011, 07:31:42 PM »

Mark,

Thanks and I agree, except I have been working with these chips on the NE64 for the past 6 years (ok, I used the 1MB version of the SPI at the start) so debugging on a real system is easy for me and I am more used to that than checking everything out with the simulator.

Now with that in mind, I may have found an issue still with selection of the proper chip.  My previous post was a bit in error in that it turned out uTasker was STILL selecting the first chip even with all the address correct.

So what I found (when I do a DIR command from ftp) was this.  I will attempt to show this as basic flow in uTasker...

At the dir the processing path goes as follows along with the virtual starting address value as follows (=> means called from previous routine/system)

=>fnDoDir                           (starting address not set)
=>uOpenNextMimeFile           (starting address passed as zero to force it to set)
=>uGetFileLength                 (starting address is now set uFILE_SYSTEM_START
                                            value which is 0x00640000)
=>fnGetParsFile                    (NOW, inside the routine, the address is zero)
=>fnGetSPI_FLASH_location  (starting address is zero)
=>fnGetSPI_Device               (starting address is zero and the returned chip is 0)

So I do not know if maybe I have an optimization issue or what, but this loss of the starting address is what I did see in the simulator. 

Now something even more interesting, if I hard-code the chip-select value to 3 in the fnGetSPI_FLASH_location instead of calling fnGetSPI_Device, everything works perfectly (really!!) and when I debug, I notice that I do NOT loose the starting address at all (as I am not using it to determine which chip) throughout the 'same' sequence I described above.

In any case, I will leave it hard-coded for now as this will remain this way for this device.  Just figured I would let you know what i found.

Thanks.

                                            - jon 

7

µTasker general / Re: How would I place the entire uTasker file system on the 4th SPI chip only

« on: October 06, 2011, 05:41:49 PM »

Thanks and once again I actually have done this and all of this is correct as you specified.

I went ahead and ported it to my eval board code and it works great.  I guess I was a bit worried from my lack of understanding of the simulator, but it is all good.

I confirmed that all of the other 3 SPI chips are not affected.  FTP works correctly as well as the pages.

Thanks again and as usual, uTasker is not as complex as it first seems.  Take care.

                                                   - Jon 

8

µTasker general / Re: How would I place the entire uTasker file system on the 4th SPI chip only

« on: October 06, 2011, 02:51:36 PM »

Thanks Mark for the file granularity info as this will help with our actual page sizes.

I appreciate the info on the various defines and must tell you I have already done this and everything matches what you have shown.  So maybe it is my confusion at the point.

I currently see a sim buffer that is the size of a single chip and this is correctly loaded with my pages.  I guess my concern was to make sure (prior to copying this to my actual system on the eval board) that I could see three chips left alone and the last chip being used.  I guess the simulator must take care of the 'chip-select' as it should based on the starting address of the file system and this is 'hidden' (though I have seen it pick correctly based on the address).

I was attempting to see a buffer that was 3/4ths empty (zeros) and the end used.  Obviously using only a single chip size for the file system, you only create a buffer that size and the system does not know anything about the other physical chips other than the starting virtual address.  This as stated should get uTasker to select via the proper CS line.

I will now move this all to the real world and make sure all remains as such.

Thanks again as always.

                                                - Jon   

9

µTasker general / How would I place the entire uTasker file system on the 4th SPI chip only

« on: October 05, 2011, 10:13:42 PM »

I am currently attempting (with the simulator) to have the uTasker file system reside on the 4th SPI chip only.  I do not use any internal flash, nor a parameter block and the first 3 SPI chips are using my own system that includes the boot loader files (I have modified the bare-minimum boot loader to handle the uTasker-style firmware upgrade format, but use my 'files' directly).

My desire is to use the 4th SPI chip (all are ST micro/Numonyx/Micron NOR SPI 'data file' chips with page erase/write, 2mB(yte) M25PE16) for the uTasker file system, specifically to handle all of my web pages.

Using the simulator, I was easily able to load a couple of my own pages using the standard setup (using internal flash).  I then 'placed' the pages in the 'first' SPI chip and all worked properly there.

I then attempted to set the various defines to set the start of the file system to the last chip and make the file system size just 2 megs.  This did not work for two reasons: 1) even though the buffer was the correct size for the chips (8mb), it is attempting to access memory beyond the buffer when the ftp command del *.* is attempted and 2) If I expose all 8 megs as the physical size of the memory, but only have the spi flash size set to 2 megs, the simulator still attempts to clear ALL 8 megs.

I do not have to span multiple chips, just one.  As far as I can see, I have the granularity set properly (it is the size of the chip's sub-sector I believe for erase purposes).

So, how would I set the uTasker defines for a 4th SPI chip-only uTasker file system.

                                                  - jon