Messages

16

NXP^TM M522XX, KINETIS and i.MX RT / Re: How to read out the stack (A7) value?

« on: July 07, 2011, 01:42:18 PM »

Hi mark
Thnaks for your reply.

Your idere are great, but there must be something wrong. ;-)
I can see that the address in the A7 are changing as I step over the creation of the variabels. And the result in the

Code: [Select]

ulStack are not the same as when i enter the interupt function.

I will try a play araound with it after the sommer, to see if I can find the problem.

Regards Steen

17

NXP^TM M522XX, KINETIS and i.MX RT / How to read out the stack (A7) value?

« on: July 01, 2011, 01:43:38 PM »

Hi.

I am in progress of making a function that read out the information mention here:http://www.utasker.com/forum/index.php?topic=123.msg468#msg468

The idere are that in case of a "unexpected error" I have the best possible information when trying to locate the error.

My problem is that I have been trying to get the value fron the A7 but with no luck.

Code: [Select]

unsigned long tmp = *((uint32*)0x08F) //Get the value from the A7 register.
   tmp  = *(uint32*)(*(uint32*)A7);    //Get the first byte mention in the above link. This is the data that A7 is pointion to.
   tmp  = *(uint32*)((*(uint32*)A7)+1);
   tmp  = *(uint32*)((*(uint32*)A7)+2);
   tmp  = *(uint32*)((*(uint32*)A7)+3);


Hope you can help me?

Best regards
Steen Larsen

18

NXP^TM M522XX, KINETIS and i.MX RT / Re: 52233 for low power use

« on: December 21, 2010, 08:45:04 AM »

Hi Mark & Neil
I am facing almost the same problem.

We have a case where our unit gets more warm that we like.(Not critical at all).

In our case we do not use fully potential of the 80MHz in 95% of the time.
My first idée was to use the SUPPORT_LOW_POWER operation, but can see that my system never will be able to get in to low power state do to 100 ms timers.

The next idée was to change the clock as runtime. This was are very fine from the theoretical point of view, but my problem are that it looks like many fundamental things in the system must be change, do you agree on this.
Any other suggestions are welcome.

Best regards
Steen Larsen

19

µTasker general / Re: Getting the MAC address from the connecting client to a TCP server

« on: October 21, 2010, 06:41:48 AM »

Hi Mark

Thanks for the reply.
You are completely right. Our systems will normally only be accessible to unit on the local net.
The idée of using the MAC address are that it is harder for a 3. person to duplicate this kind of communication.   
I will give it a try

Regards
 
Steen

20

µTasker general / Re: I2C in slave mode

« on: October 21, 2010, 06:37:04 AM »

Hi Mark

I am planning to use the SC16IS752 in the I2C interface.

The plan is to connect up to 3 SC16IS752 on the I2C interface.
We are planning to poll the SC16IS752 units and if there are data from the UART the collect them.
In our system there is a low amount of traffic so data getting lost are not a big concern at the moment.

And as the ideer was then that in some cases the SC16IS752 was replaced with the M5225X in a I2C slave configuration.

If possible I woudt like to see the driver you have made for the Luminary chip? I expect that i can resue a lot of the setup code for the SC16IS752 chip.
 
Thanks

Regards

Steen

21

µTasker general / Getting the MAC address from the connecting client to a TCP server

« on: October 20, 2010, 12:38:08 PM »

Hi Mark

Is it possible to somehow get the MAC address of the client that are trying to connect to a TCP server I uTasker?
I can see that the white list supports IP addresses, but some of our customer want it to be the MAC address that are used as white list.
I was thinking of using the ARP table, but am unsure if the ARP table always has it in its table or it need to make a lookup.
If it need to make a lookup that I am afraid that the uTasker system will get lock in circles while the ARP service are fetching the MAC address…

Regards

Steen

22

µTasker general / Re: I2C in slave mode

« on: October 20, 2010, 12:30:48 PM »

Hi Martin

Thanks for your input.

My last post was just for explaining why we have selected I2C as our buss and not one of the other communications ports available in the M5225X ;-).

The reason for having the M5225X to run as a slave unit are that in many cases there will be 2 identical (HW) units on will be configured as master and one as slave..

We are planning to use the SC16IS752 from NXP it has a dual UART and 8 SW controlled I/O.
When you say that is works well with uTasker do you mean that a driver already exist(Always on the look for things that saves me time ;-)) or that it is possible to integrate it in the uTasker?

Regards

Steen

23

µTasker general / Re: I2C in slave mode

« on: October 15, 2010, 06:48:38 AM »

Hi Mark

Too bad, that the Slave was not there ;-)

The reason for us to select the I2C as the physical buss interface is infact:
1) On the Freescale M5225X, we are all out of alternative hardware connections. We already use the LAN, 3xRS232, SPI + a SW SPI, USB. So the I2C was the only thing left, which requires a minimum of extra hardware.
2) Creating additional expansion board is easy simply using a cheap I2C -> IO chip.

To complete the circle we then had the idée that the M5225X should be able to change operation mode from master to slave module, with simple software configuration.

I guess that this means that there only is the hard way to solve this?

Regards

Steen

24

µTasker general / I2C in slave mode

« on: October 14, 2010, 02:39:25 PM »

Hi Mark

We have been using the uTasker for over 2 years and are very pleased with the performance and functions ;-).
In our upcoming products we plan to make a bus system that uses I2C. I can see that there are support for I2C master, but can’t see that the I2C slave are implemented.
Is the I2C slave hidden some ware in uTasker that I cannot see?

Regards Steen

25

NXP^TM M522XX, KINETIS and i.MX RT / MCF5223X New Mask Revision

« on: November 26, 2009, 08:01:53 AM »

Hi

Just got this link from our partner:http://www.freescale.com/files/shared/doc/pcn/PCN13905.htm?fsrch=1

It looks like the problem with the LAN speed auto negotiation has been addressed!

I have received samples of the new version a few month back but never got the time to test it
Hope that some one in here gets the time to run a few test?

Best regards
Steen

26

NXP^TM M522XX, KINETIS and i.MX RT / Re: PIT from fnInitHW

« on: October 12, 2009, 02:58:29 PM »

Hi Mark

Thanks for your reply.

It works perfect now;-)

Regards Steen

27

NXP^TM M522XX, KINETIS and i.MX RT / PIT from fnInitHW

« on: October 08, 2009, 09:29:52 AM »

Hi Mark

I am trying to port some code from a M52235 to M52255 and in this progress upgrading to the new Tuasker version 1,4.

My problem are that when I init the PIT from the fnInitHW function it is not fired until i exit the function even when i make a while{1} in the fnInitHW.

I init the PIT like this:
    pit_setup.int_type = PIT_INTERRUPT;
    pit_setup.int_handler = disk_timerproc;
    pit_setup.int_priority = PIT1_INTERRUPT_PRIORITY;
    pit_setup.count_delay = PIT_US_DELAY(10000);           // 10ms delay
    pit_setup.mode = PIT_PERIODIC;                                // repeat interrupt
    fnConfigureInterrupt((void *)&pit_setup);                     // enter interrupt for PIT1 test

Do you have any suggestion on how to get the PIT interupting the fnInitHW and thereby getting a time within the function?

Regards Steen

28

µTasker general / Re: Replacement for uFileSystem?

« on: September 11, 2009, 09:31:33 PM »

Hi JuKu

Have a look at the FatFs http://elm-chan.org/fsw/ff/00index_e.html.
The FasFs has direct support for SD card and can easily be added to the SPI port. (When adding a SD card to your own board remember to read alle the guideline regarding this....The SD card use a lot of power when a hot plug are done)
It is a generically FAT system that in theory will work with all processor and it has a small foot print.
The small footprint makes it possible also to include it into the bootloader.
 

Regards
Steen

29

NXP^TM M522XX, KINETIS and i.MX RT / Re: Malloc proble...

« on: June 12, 2009, 08:13:55 AM »

Hi Mark

Are you the best or what?
The problem was that I was using C_4i_CF_SZ_MSL.a as mention in the http://www.utasker.com/forum/index.php?topic=96.0.

But when changing the to C_4i_CF_RegABI_SZ_MSL.a as you suggested it almost work.
The malloc was returning 0. But after I recompiled the lib, it worked perfect.

Ones again you saved the day...

Many thanks

Regards Steen
 

30

NXP^TM M522XX, KINETIS and i.MX RT / Re: Malloc proble...

« on: June 11, 2009, 03:01:20 PM »

Hi Mark

The hdr are a struct of:
typedef struct tagAMX_HEADER {
  int32_t size          PACKED; /* size of the "file" */
  uint16_t magic        PACKED; /* signature */
  char    file_version;         /* file format version */
  char    amx_version;          /* required version of the AMX */
  int16_t flags         PACKED;
  int16_t defsize       PACKED; /* size of a definition record */
  int32_t cod           PACKED; /* initial value of COD - code block */
  int32_t dat           PACKED; /* initial value of DAT - data block */
  int32_t hea           PACKED; /* initial value of HEA - start of the heap */
  int32_t stp           PACKED; /* initial value of STP - stack top */
  int32_t cip           PACKED; /* initial value of CIP - the instruction pointer */
  int32_t publics       PACKED; /* offset to the "public functions" table */
  int32_t natives       PACKED; /* offset to the "native functions" table */
  int32_t libraries     PACKED; /* offset to the table of libraries */
  int32_t pubvars       PACKED; /* offset to the "public variables" table */
  int32_t tags          PACKED; /* offset to the "public tagnames" table */
  int32_t nametable     PACKED; /* offset to the name table */
  int32_t overlays      PACKED; /* offset to the overlay table */
} AMX_HEADER;

AMX_HEADER hdr;
memblock = malloc(hdr.stp);

When caling malloc(2536) I get the same result.

I think that it looks like the parameter not are passe allong when calling the malloc function.

But the reason for this do not understand.
The stdlib.h are includet in the config.h and i tried to include in the .c file aswell but with same result.

Regards
Steen