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 - Richard

Pages: 1 [2] 3
16
NXPTM M522XX, KINETIS and i.MX RT / RTC initialization
« on: March 24, 2009, 07:23:15 PM »
When I tried to use the RTC, I found that the one-minute interrupt occurred every 12 seconds.  Changing the value stored in the Real Time Clock Divide Register from
    MCF_CLOCK_RTCDR = (OSCCLK-1);
to
    MCF_CLOCK_RTCDR = (CRYSTAL_FREQ-1);
when I initialized the RTC fixed the problem.

I don't understand the theory behind the problem and its solution, since the manual clearly says that the RTC gets its 1 Hz frequency by dividing the oscillator clock by a factor of RTCDF+1, but empirically, I needed the crystal frequency -- at least that's what the macro names imply.

I should point out that I'm using my own board, not one of the Freescale (Axiom) DEMO boards, and maybe the difference is to be found there.

Best regards,
    Richard

17
Hi, all.  The 5223X has the ability to detect when the supply voltage is dropping and force an interrupt.  According to table 2.3 of the MCF52235 Data Sheet (still labeled "advance information" in revision 6!), the low voltage detect trip voltage is between 2.15 and 2.3 Volts.

I'd like to be able to save a few values in a block of internal flash between the time the low voltage interrupt occurs and power drops to a level that no longer permits reliable writing to flash.  Has anyone an idea if this is possible?  I.e., is it even possible to write to the internal flash at 2.15 Volts.  If so, how much time does it take to write one block of flash, and how long after the interrupt occurs will power still be above whatever is required to write flash?

Assume the worst case, i.e., that power fails completely while the 5223X is in its full power mode, and assume that power capacitors and resistors are as recommended by Freescale, e.g., on their demo board or Figure 5. "Suggested Connection Scheme for Power and Ground" of the MCF52235 Data Sheet. 

I guess that the first thing to do after receiving the interrupt would be to clear the Peripheral Power Management Registers (PPMRH, PPMRL) to shut down all the clocks and set all ports to be GPIO with their DDRs set to 0 (inputs) so the CPU wouldn't be sourcing more power than necessary...or is there a better way to do reduce power and still be able to write to the internal flash?

Thanks for whatever thoughts and information you may have.

    - Richard

18
NXPTM M522XX, KINETIS and i.MX RT / M5225X support
« on: December 05, 2008, 03:30:45 AM »
Hi, Mark.  A very small point:

In file M5223X.h (supports also M5213, M5222X) is the comment line
Code: [Select]
   13.08.2008   Add M5223X support                                       {24}but every time {24} appears, it seems to be associated with M5225X.  Since the file already accommodated the M5223X family, I suspect that the processor number in the comment is a typo.

Also, the line identifying the file near its beginning should probably have M5225X added to the "supports also" part.

Cheers,
    - Richard 

19
This is reminiscent of my experience with SP6 and version 7.0 of CodeWarrior (see http://www.utasker.com/forum/index.php?topic=185). I'm still not quite sure how I got them working together -- which is inhibiting my upgrading my project to SP7.

20
µTasker general / User authentication
« on: May 20, 2008, 04:47:24 AM »
Hi.  I've had a bit of trouble when I've tried to force the user to log in before accessing web pages.

To test this, I forcibly set ucHttpProperties |= WEB_AUTHENTICATE; in fnConfigureAndStartWebServer. (I'm sure there's a better permanent solution that involves setting the appropriate bit in ucServers, but for this initial test, I haven't tried to figure out the best place to do that.)

However, for reasons I don't fully understand, the routine fnWebParHandler checks to see if (ucFile == ' ') before it tries to authenticate the user.  Using SP7 and the simulator, it is apparent that ucFile has the value '0' at the time the test is made.  If I change the test in fnWebParHandler, to be if (ucFile == '0'), the user authentication appears to work as expected.

Is this the correct way to deal with user authentication for web pages, or is there something else that is more in keeping with your original intent and hence more reliable than the expedient "hack" I've created?

Best regards,
    Richard

21
Hi, Mark.
Note that it is normal that the code will be in the fnDoLowPower() call most of the time since it will sleep there until an interrupt wakes it. If you pauue the debugger it will invariably be at this code position.
Whenever I've found it there, I've not been clever enough to get the debugger to restart the program.  This brings up another question: is there some way to get the debugger to clean up its stack and reset the microprocessor?  So far, I've had to reload the program to get this to happen.  There has to be a better way!

Quote
The best way to check this is in the map file (in \Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3\bin in the demo project)

# Memory map:
  v_addr   p_addr   size     name
  00000800 00000800 0001596E .flash     flash
...
Here it is seen that the FLASH content is extending to the 86.3k mark (example form boot loader compatible code, which starts at 0x800).
I've searched quite a bit but cannot find documentation for the coldfire linker that explains what v_addr and p_addr are.  Is there a publicly available linker manual somewhere that I've failed to find?

Quote
It is possible to change the linker script (eg. M52235EVB_FLASH.lcf) to reflect the length of FLASH which can be used for code (respecting your file system set up). This would then generate an error if the code grows into that space.
Lack of a linker manual makes it a little tricky to alter the script or even interpret it in its current form.  However, after looking at it, it seems likely that changing the line in the MEMORY section to read
    flash2  (RX)   : ORIGIN = 0x00000420, LENGTH = 0x001FBE0
should limit the program to be below the area given over to the parameter blocks and file system (since 0x420+0x1FBE0 = 0x20000).

Quote
>>FLASH_SIZE to be (0x40000) -- the right value for the 5223X family
There are several in the family which have only 128k.
I had forgotten that.  I decided a while ago that they are too small for what I intend to do -- perhaps incorrectly, judging from your comment below -- so I put them out of my mind.

Quote
When using smaller types (like M52230) the boot loader can still be supported in external SPI FLASH. [Presently the samller chips together with SPI FLASH is proving to be the favourite method].
Is this only for the boot loader, or is it in general?  And is there some obvious reason (e.g., cost, availability)?

Many thanks,
    Richard

22
Hi, Mark.
Let me report some intermediate results.

(1) Stability of my experiments has been vastly improved by commenting out SUPPORT_LOW_POWER. This is something I won't need, since mains power is always available to my project.  I would occasionally find my program sitting at fnDoLowPower() and be unable to get it to go further.  At least that doesn't happen anymore.

(2) Although I haven't yet figured out how to find the maximum extent of the program code, I found that erasing from the beginning of memory to 17FFF and then trying to load my program would fail.  To check, I erased the whole memory and successfully loaded the program.  I then erased from 18000 to the end of memory and found that the program would not verify.  This gives some powerful hints as to what may be happening.

(3) I then changed uFILE_START from 0x18000 to 0x20000.  This caused subsidiary problems, mainly based on built in assumptions that the file system was 80*1024 Bytes long.

To fix this, I defined a manifest constant FLASH_SIZE to be (0x40000) -- the right value for the 5223X family.  It should be somewhere in M5223X.h, but I didn't find it -- and then defining  FILE_SYSTEM_SIZE to be (FLASH_SIZE-uFILE_START).  And then I changed the various tests that checked FILE_SYSTEM_SIZE against (160*1024) to test against a constant I called FILE_SYSTEM_ADEQUATE, which I defined to be 0x20000.  I hope that this is indeed large enough!

I still have to confirm that I have managed to write the parameters to FLASH, but I wanted to let you know the outcome of the current tests.  And I'd like to know
  (a) Is there some easy way to discover, within CodeWarrior, the highest address used by the program?
  (b) Is there a reason for starting the file system at 0x18000, which corresponds to limiting the maximum program size to something smaller than that supported by the free CodeWarrior IDE?
  (c) Is 0x20000 (=128K) large enough for whatever was being required to be 160K in your original code?

Best regards,
    Richard

23
Hi Richard

Quote
The heap size in config.h is 19 KBytes.  Just before fnSaveNewPars(SAVE_NEW_PARAMETERS) is called, fnHeapFree() returns 964,  fnHeapAvailable() returns 19456 and fnStackFree() returns 5767.

Is this before increasing the parameter structure?
This was after increasing the size of the structure; i.e., PARS has size 704.

In another experiment, I uploaded your web pages to be sure that a lot of things have run, and then I accessed the Administration page.  The Memory Utilisation table there shows
    HEAP Free 0x03c4 from 0x4c00
    STACK Unused 0x10a3

I then perform the keypad sequence that results in accessing the Heap and Stack functions. fnHeapFree() returns 964,  fnHeapAvailable() returns 19456 and fnStackFree() returns 4259.  The first two are as before, and the hex values for the free heap and unused stack shown on the web page agree with the decimal values returned by the functions.

So, it looks like there's enough room.  I'll work on this more tomorrow.

Quote
Regards and enjoy your evening!!
Thank you.  The concert was fabulous!

Best regards,
    Richard

24
I must admit to never actually using really big parameter blocks but the theoretical values that you quote should be correct. When changing the parameter block size ensure that you increment its version number so that the code doesn't try to work with an invalid one (not a problem that would normally cause crashes though).
I did increment the version number.
Quote
Note also that ram copies are made of the parameters (parameters and temp_pars) on heap - if the parameters structure is increased by 1k it results in 2k more heap being required and it may be that this is failing as the size increases - check the heap allocation size (OUR_HEAP_SIZE in config.h) and use the routines fnHeapFree(), fnHeapAvailable() and fnStackFree() to monitor these.
The heap size in config.h is 19 KBytes.  Just before fnSaveNewPars(SAVE_NEW_PARAMETERS) is called, nHeapFree() returns 964,  fnHeapAvailable() returns 19456 and fnStackFree() returns 5767.

Quote
I will have a try with big parameter blocks and look at your project when you have sent it.
I've not sent my project, because it relies on having a 16-key keypad, 11 7-segment LEDs and six LEDs and their drivers attached.  If I can figure out some way to get these same type of results with your example project and version 7.0 of the IDE, I'll send them along.  Right now, though, I have to rush off to hear Sir Neville Marriner conduct the Academy of St. Martin in the Fields.
 
Best regards,
    Richard

25
Hi, Mark.
>>As for the DMA problem, at least when running using the debugger, the code appears to hang
Are you sure that the watchdog is disabled when debugging? - otherwise it fails when breaking and trying to step.
I have never disabled the watchdog while debugging, and I've never had a hanging problem.  The only strange and annoying debugging behavior that I regularly see is that serial communication never resumes once the first breakpoint has been hit.  I've never bothered to try to figure out why, since if I'm single stepping, I am not usually making much use of the debugging data that I send out through the serial port.

To this, I must now add that further experimentation with uMemcpy() has shown the following weird debugger behavior that occurs if I single step through fnFlashNow() and then examine what is in RAM when fnRAM_code() is called.  If I do this the first time fnFlashNow() runs, it will not copy the fnRAM_code() routine into RAM, as I have already reported.  This happens even when the actual copy from FLASH to RAM is run at speed using run-to-cursor or some other way of executing the copy instructions.  However, if fnFlashNow() runs once before I hit a breakpoint, the necessary code is copied into RAM.  I confirmed this by adding two calls to fnSaveNewPars(SAVE_NEW_PARAMETERS), one right at the end of fnApplication() and another in my own routine that is called later.  If I wait until the second one is called and single step through fnFlashNow(), the fnRAM_code() routine has indeed already been copied to RAM.  This tends to confirm your comment
Quote
Therefore my assumption is that what you are observing has something to do with the operation of the debugger.

I will send you the requested copy of SP6 that hasn't worked with version 7.0 of the IDE in the next few minutes.  If you look in uTaskerSP6\Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3, you'll find a .png file that captured the various updates that took place when first run under version 7.0 of the IDE.

Right now, I'm trying to figure out the maximum size that the PARS structure can have.  From the documentation, I thought the calculation would be 2046 Bytes (FLASH_GRANULARITY - 2) diminished by the size of the NETWORK_PARAMETERS structure (24 Bytes), leaving a total of 2022 Bytes for PARS.  However, my experiments have shown that if its size is 704 Bytes, then shortly after I call fnSaveNewPars(SAVE_NEW_PARAMETERS), my program hangs completely -- so completely that I have to unpower the DEMO board and restart the IDE to again communicate with the board, even to erase its memory.  If its size is reduced to 272 Bytes, the program runs just fine.  (I find the size by disassembling application.c and then looking at the Section Size associated with _cParameters.  I have confirmed by setting breakpoints that this is the same size that's sent to fnSetPar().)  Of course, the problem could be elsewhere.  For example, I might be overlaying fnRAM_code() with the longer parameter blocks.

As you can tell, I'm still experimenting with parameter blocks.

Best regards,
    Richard

26
Hi, Mark.
Thanks for the prompt reply.
As for the RUN_LOOPS_IN_RAM issue, I didn't realize that it was unsupported.

As for the DMA problem, at least when running using the debugger and setting breakpoints, the code appears to hang, and when stopped manually is in an unimplemented interrupt routine, undef_int().  I did go back to a reasonably pure SP6 after seeing the problem with a version I've altered significantly.  It showed up in both.  By "reasonably pure", I mean that I've turned off DHCP, altered the IP addresses to be 192.168.1.x rather than 192.168.0.x, and changed the system to be the DEMO board rather than the EVB board.  To test for the DMA problem, I put a call to fnSaveNewPars(SAVE_NEW_PARAMETERS); right at the end of fnApplication().  One more thing: I've still not succeeded in running a pure SP6 using version 7.0, so in testing SP6, I reverted to version 6.4 of the IDE.

I have read version 2 of the discussion of the uTaskerFileSystem -- several times.  Does its explanation of the parameter system differ from version 3?

To keep the length of this message down, I'll attach my musings about the parameter system, which I wrote earlier today, as a text file.  If you like, feel free to answer off-line or to copy and edit the file and reply to the questions on-line, whichever you think is best for the forum.  I had intended to clean the text up a bit, but it seems more important to include it with this response, so please excuse its tendency to ramble.

Best regards,
    Richard

27
Hi, Mark.

In trying to understand parameter blocks, I seem to have run into a couple of bugs.

fnSaveNewPars(SAVE_NEW_PARAMETERS) calls (after some nesting) fnWriteLongWordFlash().  This relies on fnFlashNow().  Since it is generally not possible to execute code from FLASH when also writing to FLASH, the first time fnFlashNow() is used, it copies necessary code into RAM, using uMemcpy(), and then tries to execute the copy.

To copy more than 20 bytes (as defined by SMALLEST_DMA_COPY), uMemcpy() uses a DMA technique.  By setting breakpoints on the M52233DEMO board, I have found that in this case, the copy does not work; the relevant portion of memory contains mostly 0x00 after uMemcpy() returns.  If I set SMALLEST_DMA_COPY to some very high number, forcing a direct copy (*ptr1++ = *ptr2++;), uMemcpy() does the necessary copy and the expected code makes it into RAM.

In the process of working with this, I also tried commenting out DMA_MEMCPY_SET but defining RUN_LOOPS_IN_RAM.  This caused the compiler to complain a couple of times about an illegal constant expression.

I am using uTasker 1.3, SP6, and version 7.0 of the Codewarrior IDE, but I've tried this with version 6.4, too, and had the same results.

I am still having some difficulties understanding parameter blocks, but I'll post questions about those in the general forum when I have formulated my thoughts a little more sharply.

Best regards,
    Richard

28
µTasker general / Internet Time Service protocol
« on: March 28, 2008, 06:09:26 AM »
Hi.  I'm back to thinking about time and putting information about the time zone into the parameter block.  In the process, I stumbled across the following information about the NIST Internet Time Service (ITS) http://tf.nist.gov/service/its.htm.  They will eventually no longer support the time protocol used in the uTasker code, Time Protocol (RFC-868), which uses port 37.  They say it is used by only about 1% of their users, and they want everyone to move to Network Time Protocol (RFC-1305), which uses port 123.

Quote
Starting on 14 April 2007 the server time.nist.gov will no longer respond to requests for time in the TIME format (as defined in RFC-868). These requests are generated by a number of different programs including DATE, RDATE, and other programs that connect to the time server using tcp or udp port 37. All of the other NIST servers (except for time-nw.nist.gov) will continue to respond to requests to either tcp or udp port 37 for time in the format specified in RFC-868.

However, this format has poor error-handling capabilities in general, and many of the client programs that use this format are poorly written and may not handle network errors properly. Therefore users are strongly encouraged to switch to the Network Time Protocol (NTP), which is more robust and provides greater accuracy. We eventually intend to phase out support for the TIME format on all servers.

Please send questions or comments regarding this issue to Judah Levine: jlevine@boulder.nist.gov

For my purposes, the older, RFC-868 protocol is good enough, but I'd hate to see an application fail in the field because NIST decides to pull the plug on the service, especially since they've given warning well in advance.  So, eventually [but it could be years, who knows?] we'll all be forced to use the new protocol, or at least the simplified version of NTP, suitable for most uses, specified in RFC-4330.

Has anyone worked with this?  Has anyone written a modified version of the uTasker TIME client that makes use of the newer protocol that he would be willing to share?  Is there a simple reference version available on the Internet?  All the sample code provided by NIST uses older protocols.  All the other reference code I can find spreads the details over dozens of files -- and it can't be that hard.

I shouldn't let this stop me from figuring out how to put time zone information into the parameter block, with a way for the user to update it for summer time or a change in location (probably via a web page).

Cheers,
    Richard

29
µTasker general / time of day socket
« on: March 06, 2008, 06:15:55 AM »
Hi, Mark.

The time of day seems to drift by a couple of minutes in 24 hours, so I'd like to reset it every once in a while, maybe every ten or fifteen minutes.  In the process of looking at this, I came across the following questions:

It looks like the time of day socket, TIME_TCP_socket, is never actively released once it is opened.  Is there a built-in mechanism in uTasker for aging an unused socket into a closed state and then releasing it?  Does it rely on the remote endpoint to close the connection?  If I want to release the socket after successfully receiving the time, do I first have to do something to close the TCP connection?  If so, does it suffice to call fnTCP_close(), or do I have to "wait around" and release the socket after the close completes?

If I'm going to attempt to reconnect to a time server, I'd like to know if the TIME_TCP_socket is still available, but the routine fnGetSocketControl() is static, so I can't access it outside of tcp.c.  Is there some other way to test whether TIME_TCP_socket is still defined?  Note that, as an uninitialized external variable, it starts out life defined as 0.  From the comment at typedef USOCKET, it looks like 0 is a legal socket number.  Would it be reasonable to define UNDEFINED_SOCKET as -3 and then declare USOCKET TIME_TCP_socket = UNDEFINED_SOCKET; (making it static if appropriate)?

Then, instead of copying the existing
Code: [Select]
if ((TIME_TCP_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, TCP_DEFAULT_TIMEOUT, fnTimeListener)) >= 0) {
  fnTCP_Connect(TIME_TCP_socket, (unsigned char *)&ucTimeServers[ucTimeServerTry++], TIME_PORT, 0, 0);
}

I could write something like

Code: [Select]
if (TIME_TCP_socket < 0) {
  ucTimeServerTry = 0;    // since we're opening a new socket, we'll start at the beginning of the list.
  TIME_TCP_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, TCP_DEFAULT_TIMEOUT, fnTimeListener);
}
if (TIME_TCP_socket  >= 0) {
  fnTCP_Connect(TIME_TCP_socket, (unsigned char *)&ucTimeServers[ucTimeServerTry++], TIME_PORT, 0, 0);
}

Note that this would rely on whatever released TCP sockets to set TIME_TCP_socket back to UNDEFINED_SOCKET.

I noticed that fnReleaseTCP_Socket() returns either the socket number or a 0 if there is an error, but if 0 is indeed a legal socket number, shouldn't it return -1 in case of an error?   As it happens, the return value is not checked anywhere in the current software, so its value doesn't make a difference.

Sorry to bother you with this raft of questions, but my first attempts to write a simple task that wakes up every ten minutes to reset the time didn't quite work.

Best regards,
    Richard

30
Hi, all.

A low cost BDM for Coldfire is the AxBDM-CF, made by Axiom Manufacturing, the same people who make the M52233DEMO board.  For some reason, it's not well advertised, but you can find it at http://www.axman.com/node/303.  It costs US $99 + shipping.

Best regards,
    Richard

Pages: 1 [2] 3