Topics

1

NXP^TM M522XX, KINETIS and i.MX RT / Using PE's usb wiggler at 5MHz?

« on: May 18, 2010, 10:24:21 PM »

Hi Mark,

No, I didn't try CodeWarrior.
For years I was using CodeSourcery only and not having
an experience with CW I keep it as a last resort

Regards
Sergei.

PS: I've deleted previous topic by accident:(
Actually I was looking for way to edit my old message.

2

NXP^TM M522XX, KINETIS and i.MX RT / Is support missing for M5225X in SP9 types.h ?

« on: April 21, 2010, 03:03:01 AM »

If _M52259 is defined, then MAX_FILE_LENGTH defaults to unsigned short.
It seems strange. I would expect an unsigned long.
Thx.

3

NXP^TM M522XX, KINETIS and i.MX RT / SW timer fires too early

« on: August 07, 2009, 09:41:05 PM »

Hi,

This problem has been discussed in January 2008:
http://www.utasker.com/forum/index.php?topic=158.0
The fix was suggested then and I have it incorporated into my code.
Can anybody confirm that suggested fix definitely cures problem.
Recently I’ve realized that in my project early firing happen very often
(but not in 100% cases) after timer was stopped before.

Thx,
Sergei.

4

NXP^TM M522XX, KINETIS and i.MX RT / SRAM state after SW reset?

« on: July 10, 2009, 08:10:31 PM »

CFM52235 RM says that state of SRAM is undefined after HW reset .
What about SW reset?
Looks like there are two possibilities: to be udefined or to be unchanged.
Link to document ( or firm statement:) ) will be appreciated.

Thanks,
S.Y.

5

NXP^TM M522XX, KINETIS and i.MX RT / Weird HW timer & Happy New Year

« on: December 30, 2008, 08:08:13 PM »

Two HW timer are created and used in similar way in project based on uTasker SP5, but
10ms timer fired in 10ms
40ms timer fired in 30ms

#define T_RAMP_DLY            (CLOCK_LIMIT)(10.0*MILLISEC)        // do next step
#define T_MODE_DLY            (CLOCK_LIMIT)(40.0*MILLISEC)        // wait for integrator to be ballanced

uTaskerGlobalMonoTimer( (UTASK_TASK)(OWN_TASK | HARDWARE_TIMER), T_RAMP_DLY, E_RAMP );
uTaskerGlobalMonoTimer( (UTASK_TASK)(OWN_TASK | HARDWARE_TIMER), T_MODE_DLY, E_MODE );

What might be the reason? Thx.

Best wishes to all

6

NXP^TM M522XX, KINETIS and i.MX RT / DMA Timer Configuration or else

« on: November 16, 2008, 04:18:57 AM »

Hi all,

To use DMA timer #3 in input capture mode, timer was configured using function

void config_dma_timer_3(void)
{
   DMA_TIMER_SETUP ptrSettings;                                         // configuration parameters

   ptrSettings.mode = DMA_TIMER_ENABLE_CLOCK_DIVIDER |                  // DMA timer operation mode
                       DMA_TIMER_CAPTURE_RISING |
                       DMA_TIMER_FREERUN |
                       DMA_TIMER_INTERNAL_CLOCK;
   ptrSettings.int_handler = dma_timer3_service;                        // Interrupt handler to be configured
   ptrSettings.int_type = DMA_TIMER_INTERRUPT;                          // Identifier for when configuring
   ptrSettings.int_priority = DTIM3_INTERRUPT_PRIORITY;                 // Priority the user wants to set
   ptrSettings.channel = 3;                                             // DMA timer channel (0..3)
   ptrSettings.clock_divider = BUS_CLOCK_DIRECT;                        // internal bus clock divided by 1
   //ptrSettings.count_delay =                                          // count delay until interrupt (clocks or external pulses)
   fnConfigureInterrupt(&ptrSettings);
}

Now input capture works perfect, but all attempts to read state of timer_3 input pin failed.
Macros ( PORTIN_SETTC & (1<<3)) always == 1 regardless of real state of input (high or low).
GPT timer has GPT_Port_Data_Register (GPTPORT) which could be used to read state of input pin.
Looks like there is nothing similar for DMA timers.
Is it possible at all to do what I want using DMA timers?

Any ideas?
Thanks.

7

NXP^TM M522XX, KINETIS and i.MX RT / Can one use fnFlush(..., FLUSH_TX) on ontput buffers?

« on: July 29, 2008, 05:58:42 PM »

At first glance it looks OK, but has anyone positive experience of doing so?
Thx.

8

NXP^TM M522XX, KINETIS and i.MX RT / GNU ld ?: meaning of *(.text .text.*)

« on: May 10, 2008, 10:07:16 PM »

There is a line
*(.text .text.*)
in linker file m52235evb-rom.ld.
What does it exactly mean?
In GNU ld manuals I've found:

"For example,
.text . : { *(.text) }
and
.text : { *(.text) }
are subtly different. The first will set the address of the `.text' output section to the
current value of the location counter. The second will set it to the current value of the
location counter aligned to the strictest alignment of a `.text' input section."

"There are two ways to include more than one section:
*(.text .rdata)
*(.text) *(.rdata)
The difference between these is the order in which the `.text' and `.rdata' input sections
will appear in the output section. In the frst example, they will be intermingled, appearing
in the same order as they are found in the linker input. In the second example, all `.text'
input sections will appear first, followed by all `.rdata' input sections."

Thx.
Sergei.