Nabble - Coldfire

RE: Coldifre and LCD

2009-10-13T07:06:36Z

Good day.

We very successfully put together a project based on the 5329.
Excellent processor! We used (and are using) the MQX OS along with the
PEG windowing system with great results. I can't say the current
availability of hardware development boards - as I recall we used
LogicPD to start with before we had our boards. The nice thing about
the PEG Window system you can do a large part of your software
(especially the UI) on a standard PC long before you have any hardware.
Feel free to contact me if you'd like to talk about it.
rbystrianyk@....

Enjoy your day!
Roman

-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...]
On Behalf Of Sam Saprunoff
Sent: Monday, October 12, 2009 12:54 PM
To: Bystrianyk, Roman
Subject: [ColdFire] Coldifre and LCD

Good day All,

I have been looking at a new hardware design that requires Ethernet and
an LCD interface (TFT and ideally with an on-board LCD controller) and
so I had originally thought that the MCF5329 would be a nice choice.
The 5329 would allow us to reuse some of our Coldfire code and the
processor would allow a migration path to uCLinux, etc in the future.
As this project now moves forward and I spend more time looking at
various development options, I am seeing very little (stocked) 3rd party

development boards that utilize the 5329. For example dev boards from
LogicPD (FireEngine, etc) do not seem to be stocked anywhere and the
Cobra5329 do not seem to be overly well marketed.

That being said, I was curious if others are seeing this too, or am I
just not very good at finding items on the net? Further, is there maybe

a subtle push from Freescale to migrate to the iMX series... for LCD,
Ethernet, and Linux applications?

Thanks to all for all your comments!

Cheers,

Sam
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

LEGAL NOTICE:
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s)
only. Access to this e-mail by anyone else is unauthorized. If
you are not an addressee, any disclosure or copying of the
contents or any action taken (or not taken) in reliance on it
is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Coldifre and LCD

2009-10-12T09:53:37Z

Good day All,

I have been looking at a new hardware design that requires Ethernet and
an LCD interface (TFT and ideally with an on-board LCD controller) and
so I had originally thought that the MCF5329 would be a nice choice.
The 5329 would allow us to reuse some of our Coldfire code and the
processor would allow a migration path to uCLinux, etc in the future.
As this project now moves forward and I spend more time looking at
various development options, I am seeing very little (stocked) 3rd party
development boards that utilize the 5329. For example dev boards from
LogicPD (FireEngine, etc) do not seem to be stocked anywhere and the
Cobra5329 do not seem to be overly well marketed.

That being said, I was curious if others are seeing this too, or am I
just not very good at finding items on the net? Further, is there maybe
a subtle push from Freescale to migrate to the iMX series... for LCD,
Ethernet, and Linux applications?

Thanks to all for all your comments!

Cheers,

Sam
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Re: TCPIP stacks for Coldfire

2009-10-11T23:19:33Z

Hi Bob,

I use lwip with success.
There is also µC/TCP-IP from micrium (not tested).

Regards,
Nicolas

Bob Furber a écrit :

> Can anyone make any recommendations on TCPIP stacks for the Coldfire
> and the MCF5282 in particular?
>
> We have been using OpenTCP with mixed results. The biggest problem
> with OpenTCP is there is no user mailing list or forum to discuss issues.
>
> I understand there is a lwIP port to the Coldfire and there may be
> others, too.
>
> Thanks,
>
> Bob Furber
>
> ---
> coldfire@... Send a post to the list.
> coldfire-join@... Join the list.
> coldfire-digest@... Join the list in digest mode.
> coldfire-leave@... Leave the list.
>
>

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

TCPIP stacks for Coldfire

2009-10-09T16:15:30Z

Can anyone make any recommendations on TCPIP stacks for the Coldfire and
the MCF5282 in particular?

We have been using OpenTCP with mixed results. The biggest problem with
OpenTCP is there is no user mailing list or forum to discuss issues.

I understand there is a lwIP port to the Coldfire and there may be
others, too.

Thanks,

Bob Furber

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Programming internal flash of the MCF52XXX with Green Hills multi and probe

2009-06-10T09:49:29Z

Hello,
Has anyone programmed the internal flash of any V2 MCU using Green Hills
Multi IDE and Green Hills probe?
Thank-you
Dennis Essenmacher
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

for information : tutorial about uCllinux installation (MCF5329 Fire Engine module - Ubuntu 9.04)

2009-06-04T11:06:12Z

Hello,

I made a tutorial (in French ... :-/ ) about the uCllinux installation
(with LTIB). It is an installation on the Freescale MCF5329 Fire
Engine module, and the development computer is under Ubuntu 9.04. It's
a summary of my experience.
I will translate this tutorial soon (I hope it will be done before this summer).

http://doc.ubuntu-fr.org/tutoriel/freescale_coldfire

Best Regards.

Val
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

MCF5307, cannot debug, code is directly executed at first step

2009-06-03T04:25:11Z

Hi all,

i am new to Coldfire world, and i am using CodeWarrior to debug some test code on a MCF5307.

The code is compiled correctly, then the debugger download it through BDM, and CW shows out the fist line of my "main" code function, with the code ready to be executed.

Pressing "Step Into" the program is executed, and i get the following message:

Program "loader.elf" is executing.
Choose Break from the Debug menu to stop it.

So i cannot step line by line.

Any help is really appreciated.

Angelo

MCF52223 ADC power and ADC reference connections

2009-05-11T15:06:26Z

I'm trying to find out how best to connect the power delivery for the ADC and how to connect up the reference for the ADC to obtain the best performance. However, the docs. are lacking.

One thought is to connect both together to a precision source. Another is to power the ADC from either the same source or a filtered version of the processor's core power and power the reference from another precision source.

Any links to info. would be greatly appreciated.

Thanks,
Harjit

Hotmail® has a new way to see what's up with your friends. Check it out. coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

MCF5282 DMA

2009-05-11T11:27:42Z

Hello,

Does anyone know if it is possible to trigger two DMA transfers from a
single DMA Timer Request?

I have look through the documentation; however, I have been unable to
locate a clear-cut answer. Any help or suggestions regarding the DMA
would be greatly appreciated.

Daniel J. Sandahl
Telco Testing Solutions

[DSandahl.vcf]

begin:vcard fn:Daniel Sandahl n:Sandahl;Daniel org:Telco Testing Solutions;Engineering adr:;;4405 East Baseline Road #123;Phoenix;Arizona;85042;United States of America email;internet:DSandahl@... tel;work:(480) 603-1828 tel;fax:(480) 603-3003 url:http://www.telcotesting.com/ version:2.1 end:vcard

MCF5374 PCI->XLB->FLEXBUS aligned transfers hang the core?

2009-05-01T08:20:04Z

I have ported a previously working USB host EHCI driver from an MCF5373 with an internal USB host to an MCF5474 with an NXP ISP1564 HS USB PCI Host controller on the PCI bus. The USB controller is a PCI bus master and it initiates transfers over the PCI bus, which then accesses the Flex bus via the XLB bus.

During the setup phase 8 byte command packets are sent and these are located in a 32 bit wide SRAM on a chip select. If the command is not on an 8 byte boundary then it works as expected. If the transfer is on an 8 byte boundary then the CPU seems to halt. If I hit break in my debugger then the PC is on the first instruction of my XLB interrupt handler. If I hit run then the interrupt handler runs and reports a bus error at the address of my command packet. It indicates that it is an 8 byte burst transfer on the XLB.

If I make the XLB timeout very big, e.g. 8191, clocks then I don't get a bus timeout but the processor still gets stuck. When I hit break it is always on the first instruction of an unrelated DMA interrupt handler. If I run then the USB transaction completes successfully and the processor halts at the next one, and so on.

Note the debugger is not having to do a force TA, it is simply asserting BKPT and waiting for FREEZE.

I can't see how this is anything other than a bug in the CPU. What state can the CPU be in where it is not processing instructions but it will respond to BKPT?

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Help with the SEC on an MCF5485

2009-04-23T08:47:46Z

Help with the SEC on an MCF5485

--------------------------------------------------------------

From: James Edwards <jamesDOTedwardsATcentriliftDOTcom>

To: coldfire@...

Subject: PROBLEM WITH LOADING PRODUCT

Help with the SEC on an MCF5485

--------------------------------------------------------------

Hi WildeRice Gang,

This is my first post. I was pointed here by Bob McMillan at Future Electronics. He said a lot of good things about the list.

My Problem is that I’m having some grief figuring out how to use the Security Encryption Controller (SEC) on the MCF5485.

I’ve asked for some help on the FreeScale Forum but have not received any so I’m sending this to out you. In the hope that some of you have already conquered the SEC. I would like to use the SEC to calculate an MD5 check sum for a file.

You can check out my post, and all my replied to myself on the FreeScale Message board at the link below (I Hope it is OK to link to their message board on the wildrice list)

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=6638

I’ve pasted a few snippets of C code in there. It’s getting too long to paste into an email. If you want to / need to see the source files let me know and I’ll send them to you.

As of today I’ve stopped statically assigning both Crypto channels to the MDEU during initialization because I was getting a channel already assigned error. I think the Header for the first Descriptor just goes out and grabs the MDEU if it is not already in use anyway.

Now I’m stuck just after loading Fetch Register Zero (FR0) with a pointer to the Head of my first Descriptor (the Descriptor structure and how I’m building the Descriptor chain are on the link above) I’m not seeing a done bit or an error bit set in SEC Interrupt Status Register High (SISRH). When I hit a break point in Debug using CodeWarrior 6.4’s View \ Register Details, I can see my first Descriptor in the Crypto-Channel Descriptor Buffer for Channel Zero (CBUF0) but it will not move on to the next Descriptor in the chain even though the Pointer to the “Next Descriptor” in the chain looks correct to me. And the CCPSRH0 seems to be stuck in state 0x1B.

Also do Crypto-Channel Zero and channel One really share the same Descriptor Buffer MBAR+ 0x22080-0x220BF ??? I’m only asking because I think I’ve found an error in Rev 4 of the Reference manual. See the link above for more on that.

I sure could use a nudge in the right direction.

Thanks for any advice you can give me on this.

James

THIS EMAIL AND ANY ATTACHED FILES ARE CONFIDENTIAL AND MAY BE LEGALLY PRIVILEGED. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

===============================================================

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Question (probably often repeated) about "Unable to mmap process text, errno 12"

2009-04-21T00:33:56Z

Hi Mark,

Mark Laubach wrote:
> I'm new to uClinux and also new to using Coldfire. Sorry this is a repeat
> question, but I could use some pointers. I'm trying to run a large program
> for the first time on a stock kernel configuration on an M5208EVBE.

I assume from the boot traces below you are using linux-2.6.17-uc1?

>>From what I've read on previous lists and via google searches, it looks
> to me that this program should load and run or that I've got to increase
> maximum program size from 1MB to 8MB. Can someone confirm and give me some
> pointers with some supplemental guidance?

By default the kmalloc limit was about 1MB on 2.6.17 I think.

IIRC on 2.6.17 you want to enable the CONFIG_LARGE_ALLOCS kernel
config option to allow kmalloc's up to 32MB maximum. You can find
that option and set it using any of your favourite config make's
(config, menuconfig, xconfig, etc), in the "Processor type and
features" section.

(On newer kernel versions this is done a little differently).

Regards
Greg

> To cut down on this email size: /proc/meminfo, /proc/slabinfo, and kernel
> reboot messages are at: http://www.matmos.com/memprob/index.html
>
> Thanks for any pointers and help.
>
> Cheers,
> Mark Laubach
>
>
> Allocation of length 1352000 from process 68 failed
> DMA per-cpu: empty
> DMA32 per-cpu: empty
> Normal per-cpu:
> cpu 0 hot: high 6, batch 1 used:1
> cpu 0 cold: high 2, batch 1 used:0
> HighMem per-cpu: empty
> Free pages: 24272kB (0kB HighMem)
> Active:501 inactive:246 dirty:0 writeback:0 unstable:0 free:6068 slab:585
> mapped:0 pagetables:0
> DMA free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
> pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 32 32
> DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
> pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 32 32
> Normal free:24272kB min:724kB low:904kB high:1084kB active:2004kB
> inactive:984kB present:32768kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB
> present:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> DMA: empty
> DMA32: empty
> Normal: 32*4kB 4*8kB 1*16kB 1*32kB 0*64kB 0*128kB 2*256kB 0*512kB 1*1024kB
> 1*2048kB 5*4096kB = 24272kB
> HighMem: empty
> Unable to mmap process text, errno 12
>
>
>
>
> ---
> coldfire@... Send a post to the list.
> coldfire-join@... Join the list.
> coldfire-digest@... Join the list in digest mode.
> coldfire-leave@... Leave the list.
>
>

--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@...
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Re: V4 core speculative execution?

2009-04-15T02:43:31Z

Hi Tim,
Sorry I was mistaken. 55555555 is cacheable and changing it to a non-cacheable address stops the bus error. The problem is though that 55555555 was just an arbirtary example. In general it could be anywhere, including I/O address, where random reads could cause some very obscure bugs.

Regards, Chris

2009/4/15 nop head <nop.head@...>

Hi Tim,

We have our RTOS running very reliably on V4E processors and aren't
having any problems like this. These issues are related to your
RAMBAR, ACR, and MMU configuration, and whether regions are set for
precise or imprecise accesses. Imprecise mode allows speculative
accesses, precise mode doesn't.

Yes I also have an RTOS running and as far as I can tell that works. Normally in C pointers point to a valid object, or one past the end of an array, or are NULL, in which case you could get away with speculatively derefencing them as long as address 0 was readable. It is only where I have unions where a pointer and a scalar share the same 32 bit field.

I am not using the MMU. 55555555 matches no ACRs RAMBARs or chip selects so it should use the default cache mode in CACR which is inhibited precise.

> Why does it sometimes lock the processor rather than giving an XLB
> interrupt.

May be related to the fact that bus errors in background debug mode
can hang the processor.

It locks up even with BDM not connected. When BDM is connected the debugger has to assert reset to get the CPU to enter background mode.

Oddly if I set A0 to an invalid address that doesn't make the branch condition, e.g. 55555554, then it actually tries to jump to that address and always gets an XLB bus error as expected. It only seems to be this speculative fetch that sometimes locks up, sometimes bus errors. For a particular program it will always do the same thing but if code moves about a bit it can either work, lock up, or bus error.

I don't know whether this just applies to pointers to function or whether pointers to objects could be speculatively dereferenced as well. It seems like a major bug in the core but I can't find any referenc to it. I do vaguely remember a few years ago reading that somebody had to make address 0 readable to prevent bus errors on NULL pointers. I foolishly thought such a major bug would have been fixed by now.

The really wierd thing is that having an active breakpoint seems to fix it. Does that mean that having a dormant breakpoint modifies the processors prefetch behavior, reducing its performance? If so, it allows a whole new class of Heisenbugs.

Chris

Best regards,
Tim

nop head wrote:

I am having a problem with code that works on 68K and V3 Coldfires not working on V4. I find it hard to believe, but it looks like the V4 core partially executes code that is branched around. Here is a distilled example of the sort of code that fails, not pretty but I think it is valid C: -

typedef void (*f_ty)(void); // a function pointer

// A union of an integer and a pointer, initialised to an integer that is not a valid address
union {
int x;
f_ty f;
} p = { 0x55555555 };

// This is the sort of sequence that fails
{
dword d = p.x;
f_ty f = p.f;
if(d != 0x55555555)
f();
}

This compiles to: -

movea.l _p,a0
cmpa.l #0x55555555
beq.s skip
jsr (a0)
skip

So a0 should contain all 5's, which is not a valid address in my map, but the branch should prevent it being used as an address. What actually happends seems to depend on the code alignment, etc.

It can simply run past the code OK.

It can give an XLB interrupt with 55555554 in the address capture register.

It can lock up the processor. When I hit break in my BDM debugger the PC is a couple of instructions past this block.

If I set a breakpoint anywhere in the program the code runs OK, regardless of whether the breakpoint is triggered.

So it looks like the core sometimes does a pre-fetch on 55555555, even though it will not be executed. My questions are: -

Is this a known bug/feature in the V4 core?
Why does it sometimes lock the processor rather than giving an XLB interrupt.
Why does having a breakpoint active make it work?
Is that a workaround or do I have to find all the places in my code that this could happen an insert NOPs or something. A complete nightmare because I have a whole state machien architecture that relies on being able to contain addresses and some flags in the same 32 bit value!

Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

------------------------------------------------------------
Tim Stoutamore, Principal Engineer
Blunk Microsystems, LLC
6576 Leyland Park Drive
San Jose, CA 95120-4558
Tel: 408/323-1758
stout@...
www.blunkmicro.com
------------------------------------------------------------
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: V4 core speculative execution?

2009-04-15T02:01:19Z

Hi Tim,

We have our RTOS running very reliably on V4E processors and aren't
having any problems like this. These issues are related to your
RAMBAR, ACR, and MMU configuration, and whether regions are set for
precise or imprecise accesses. Imprecise mode allows speculative
accesses, precise mode doesn't.

Yes I also have an RTOS running and as far as I can tell that works. Normally in C pointers point to a valid object, or one past the end of an array, or are NULL, in which case you could get away with speculatively derefencing them as long as address 0 was readable. It is only where I have unions where a pointer and a scalar share the same 32 bit field.

I am not using the MMU. 55555555 matches no ACRs RAMBARs or chip selects so it should use the default cache mode in CACR which is inhibited precise.

> Why does it sometimes lock the processor rather than giving an XLB
> interrupt.

May be related to the fact that bus errors in background debug mode
can hang the processor.

It locks up even with BDM not connected. When BDM is connected the debugger has to assert reset to get the CPU to enter background mode.

Oddly if I set A0 to an invalid address that doesn't make the branch condition, e.g. 55555554, then it actually tries to jump to that address and always gets an XLB bus error as expected. It only seems to be this speculative fetch that sometimes locks up, sometimes bus errors. For a particular program it will always do the same thing but if code moves about a bit it can either work, lock up, or bus error.

I don't know whether this just applies to pointers to function or whether pointers to objects could be speculatively dereferenced as well. It seems like a major bug in the core but I can't find any referenc to it. I do vaguely remember a few years ago reading that somebody had to make address 0 readable to prevent bus errors on NULL pointers. I foolishly thought such a major bug would have been fixed by now.

The really wierd thing is that having an active breakpoint seems to fix it. Does that mean that having a dormant breakpoint modifies the processors prefetch behavior, reducing its performance? If so, it allows a whole new class of Heisenbugs.

Chris

Best regards,
Tim

nop head wrote:

I am having a problem with code that works on 68K and V3 Coldfires not working on V4. I find it hard to believe, but it looks like the V4 core partially executes code that is branched around. Here is a distilled example of the sort of code that fails, not pretty but I think it is valid C: -

typedef void (*f_ty)(void); // a function pointer

// A union of an integer and a pointer, initialised to an integer that is not a valid address
union {
int x;
f_ty f;
} p = { 0x55555555 };

// This is the sort of sequence that fails
{
dword d = p.x;
f_ty f = p.f;
if(d != 0x55555555)
f();
}

This compiles to: -

movea.l _p,a0
cmpa.l #0x55555555
beq.s skip
jsr (a0)
skip

So a0 should contain all 5's, which is not a valid address in my map, but the branch should prevent it being used as an address. What actually happends seems to depend on the code alignment, etc.

It can simply run past the code OK.

It can give an XLB interrupt with 55555554 in the address capture register.

It can lock up the processor. When I hit break in my BDM debugger the PC is a couple of instructions past this block.

If I set a breakpoint anywhere in the program the code runs OK, regardless of whether the breakpoint is triggered.

So it looks like the core sometimes does a pre-fetch on 55555555, even though it will not be executed. My questions are: -

Is this a known bug/feature in the V4 core?
Why does it sometimes lock the processor rather than giving an XLB interrupt.
Why does having a breakpoint active make it work?
Is that a workaround or do I have to find all the places in my code that this could happen an insert NOPs or something. A complete nightmare because I have a whole state machien architecture that relies on being able to contain addresses and some flags in the same 32 bit value!

Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

------------------------------------------------------------
Tim Stoutamore, Principal Engineer
Blunk Microsystems, LLC
6576 Leyland Park Drive
San Jose, CA 95120-4558
Tel: 408/323-1758
stout@...
www.blunkmicro.com
------------------------------------------------------------
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: V4 core speculative execution?

2009-04-14T12:49:02Z

Chris,

> I find it hard to believe, but it looks like the V4
> core partially executes code that is branched around.

We have our RTOS running very reliably on V4E processors and aren't
having any problems like this. These issues are related to your
RAMBAR, ACR, and MMU configuration, and whether regions are set for
precise or imprecise accesses. Imprecise mode allows speculative
accesses, precise mode doesn't.

> Why does it sometimes lock the processor rather than giving an XLB
> interrupt.

May be related to the fact that bus errors in background debug mode
can hang the processor.

Best regards,
Tim

nop head wrote:

> I am having a problem with code that works on 68K and V3 Coldfires not
> working on V4. I find it hard to believe, but it looks like the V4 core
> partially executes code that is branched around. Here is a distilled
> example of the sort of code that fails, not pretty but I think it is
> valid C: -
>
> typedef void (*f_ty)(void); // a function pointer
>
> // A union of an integer and a pointer, initialised to an integer that
> is not a valid address
> union {
> int x;
> f_ty f;
> } p = { 0x55555555 };
>
> // This is the sort of sequence that fails
> {
> dword d = p.x;
> f_ty f = p.f;
> if(d != 0x55555555)
> f();
> }
>
> This compiles to: -
>
> movea.l _p,a0
> cmpa.l #0x55555555
> beq.s skip
> jsr (a0)
> skip
>
> So a0 should contain all 5's, which is not a valid address in my map,
> but the branch should prevent it being used as an address. What actually
> happends seems to depend on the code alignment, etc.
>
> It can simply run past the code OK.
>
> It can give an XLB interrupt with 55555554 in the address capture register.
>
> It can lock up the processor. When I hit break in my BDM debugger the PC
> is a couple of instructions past this block.
>
> If I set a breakpoint anywhere in the program the code runs OK,
> regardless of whether the breakpoint is triggered.
>
> So it looks like the core sometimes does a pre-fetch on 55555555, even
> though it will not be executed. My questions are: -
>
> Is this a known bug/feature in the V4 core?
> Why does it sometimes lock the processor rather than giving an XLB
> interrupt.
> Why does having a breakpoint active make it work?
> Is that a workaround or do I have to find all the places in my code that
> this could happen an insert NOPs or something. A complete nightmare
> because I have a whole state machien architecture that relies on being
> able to contain addresses and some flags in the same 32 bit value!
>
> Chris
>
>
> coldfire@... Send a post to the list.
> coldfire-join@... Join the list. coldfire-digest@...
> Join the list in digest mode. coldfire-leave@... Leave the list.

------------------------------------------------------------
Tim Stoutamore, Principal Engineer
Blunk Microsystems, LLC
6576 Leyland Park Drive
San Jose, CA 95120-4558
Tel: 408/323-1758
stout@...
www.blunkmicro.com
------------------------------------------------------------
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

V4 core speculative execution?

2009-04-14T09:45:19Z

I am having a problem with code that works on 68K and V3 Coldfires not working on V4. I find it hard to believe, but it looks like the V4 core partially executes code that is branched around. Here is a distilled example of the sort of code that fails, not pretty but I think it is valid C: -

typedef void (*f_ty)(void);         // a function pointer

// A union of an integer and a pointer, initialised to an integer that is not a valid address
union {
    int x;
    f_ty f;
} p = { 0x55555555 };

// This is the sort of sequence that fails
{
       dword d = p.x;
        f_ty f = p.f;
        if(d != 0x55555555)
             f();
}

This compiles to: -

     movea.l _p,a0
     cmpa.l #0x55555555
     beq.s    skip
     jsr       (a0)
skip

So a0 should contain all 5's, which is not a valid address in my map, but the branch should prevent it being used as an address. What actually happends seems to depend on the code alignment, etc.

It can simply run past the code OK.

It can give an XLB interrupt with 55555554 in the address capture register.

It can lock up the processor. When I hit break in my BDM debugger the PC is a couple of instructions past this block.

If I set a breakpoint anywhere in the program the code runs OK, regardless of whether the breakpoint is triggered.

So it looks like the core sometimes does a pre-fetch on 55555555, even though it will not be executed. My questions are: -

Is this a known bug/feature in the V4 core?
Why does it sometimes lock the processor rather than giving an XLB interrupt.
Why does having a breakpoint active make it work?
Is that a workaround or do I have to find all the places in my code that this could happen an insert NOPs or something. A complete nightmare because I have a whole state machien architecture that relies on being able to contain addresses and some flags in the same 32 bit value!

Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

RE: Question about FlexCAN module and uClinux-dist-20080808

2009-04-10T08:09:05Z

Hi Val,
Look at page 9 of the AN3408.
Near Top of page:
One of the largest submenus with further submenus is Device drivers. All
available device drivers are
selected here. Most of the drivers can be built as a module, part of the
kernel, or not at all. For this example,
select all the suggested options to be built as the part of the kernel
(not as module) to simplify loading of
them.
Near Bottom of page:
Look at the Character devices submenu. Enable the following options:
* Virtual terminal
* Inside Serial drivers, enable ColdFire serial support
* Legacy (BSD) PTY support
Look at page 10 of the AN3408.
Top of page:
ColdFire FlexCAN module support and CAN0 - To have CAN4Linux drivers for
the FlexCAN
module on MCF5329

Also as reference, when you had mounted the LTIB iso, the root directory
has a START_HERE.htm file that is really goood reading via browser. It
also have configuration directions for testing ColdFire peripherals.
It even has the test procedure used to test the FlexCAN module.

Note that when using LTIB (./ltib -c) you must select "Config the
kernel" so that configuration window will open to give you access to the
"Device Drivers" configuration window, then "Character devices" to gain
access to the "ColdFire FlexCAN module support" at the bottom of the
window.

Best Regards,
David
David E Seymour

http://www.freescale.com/coldfire

-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...]
On Behalf Of Valentin Rouquette
Sent: Tuesday, March 03, 2009 8:55 AM
To: Seymour David-RA2693
Subject: [ColdFire] Question about FlexCAN module and
uClinux-dist-20080808

/* Sorry for my poor English */

Hi,

I test uClinux on Freescale Coldfire MCF5329. I work with the "Zoom
Coldfire SDK Development Kit". For my first task, I design a
CAN-Ethernet bridge. For this, I follow step-by-step the application
note "AN3408 - Building a Sample CGI Application" from Freescale. For
the moment, I search a build a correct uClinux image (with CAN driver
!). A lot of points are OK (I build an uClinux image, I send and run it
with dBug program, ...). But, in the uClinux kernel configuration menu,
I don't find the "ColdFire FlexCAN module support" option (To have
CAN4Linux drivers for the FlexCAN module on MCF5329 - page 10 of the
application note). This is the only option (of the application note,
pages 6=>12) that I can not find.

Anyone knows its location ?

I work with the latest uClinux-dist (20080808), but I have the same
problem with all previous distribution of uClinux (20070130, 20060803,
20051110).

Thanks.

Val
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Question (probably often repeated) about "Unable to mmap process text, errno 12"

2009-04-09T19:58:59Z

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: ****: 4.000000 GreyPassed=1.0, DodgySource=2.0, SPF Default Fail=1.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

Greetings to the list,

I'm new to uClinux and also new to using Coldfire. Sorry this is a repeat
question, but I could use some pointers. I'm trying to run a large program
for the first time on a stock kernel configuration on an M5208EVBE.

From what I've read on previous lists and via google searches, it looks
to me that this program should load and run or that I've got to increase
maximum program size from 1MB to 8MB. Can someone confirm and give me some
pointers with some supplemental guidance?

To cut down on this email size: /proc/meminfo, /proc/slabinfo, and kernel
reboot messages are at: http://www.matmos.com/memprob/index.html

Thanks for any pointers and help.

Cheers,
Mark Laubach

Allocation of length 1352000 from process 68 failed
DMA per-cpu: empty
DMA32 per-cpu: empty
Normal per-cpu:
cpu 0 hot: high 6, batch 1 used:1
cpu 0 cold: high 2, batch 1 used:0
HighMem per-cpu: empty
Free pages: 24272kB (0kB HighMem)
Active:501 inactive:246 dirty:0 writeback:0 unstable:0 free:6068 slab:585
mapped:0 pagetables:0
DMA free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 32 32
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 32 32
Normal free:24272kB min:724kB low:904kB high:1084kB active:2004kB
inactive:984kB present:32768kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: empty
DMA32: empty
Normal: 32*4kB 4*8kB 1*16kB 1*32kB 0*64kB 0*128kB 2*256kB 0*512kB 1*1024kB
1*2048kB 5*4096kB = 24272kB
HighMem: empty
Unable to mmap process text, errno 12

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

RE: wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T15:38:58Z

Hi Chris,

Yes MBAR is 0x1000_0000.

The nop are my way of viewing the code more easily and should I need to patch another instruction in I have room to do so.

But nop insturction does sync the pipeline and ensure writes have completed before moving onto the next instruction so maybe that is helping????

WDEBUG should be a supervisor instruction access.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 5:23 PM
To: Seymour David-RA2693
Subject: Re: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

David,

I assume your MBAR was at 0x10000000? Why do you have NOPs around the wdebug?

I am at home at the moment. I will double check my findings tomorrow at work.

I had to disable the XLB interrupt to get past the wdebug and then reset the bit in the status register before enabling the interrupt again. I can't think what would cause it. My code and data are in flash, mapped with CS0, read only. MBAR is at 80000000.

Am I right to assume the WDEBUG read of the data will be in supervisor data or instruction space? Odd that the address captured by the XLB was half way through the data.

Chris

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Ouch...just got everything put away! That serves me right for once trying to keep a clean office. Lesson learned. Thx!!

Ok...re-ran with following code:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 207C 0002 0000       MOVEA.L   #0x00020000,A0
0002000E: 4E71                 NOP
00020010: 4E71                 NOP
00020012: FBD0 0003            WDEBUG    (A0)

00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 227C 1000 0248       MOVEA.L   #0x10000248,A1
00020020: 2211                 MOVE.L    (A1),D1

00020022: 4E71                 NOP
00020024: 4E71                 NOP
00020026: 4E4F                 TRAP      #0x0F
00020028: 37FE                 DC.W      0x37FE
dBUG> rm pc 20008
dBUG> go
dBUG> rd
PC: 00020028 SR: 2004 [t.Sm.000...xnZvc]
An: 00020000 10000248 00000000 00000000 00000000 00000000 00000000 03FFFFF8
Dn: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dBUG>

Register D1 is zero so bit 8 is not setting.

Anything else for me to try?

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 4:11 PM
To: Seymour David-RA2693
Subject: Re: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

Hi David,
Yes I think it kills my PSTCLK, but why does it generate an XLB interrupt? Can you look at the XLB registers as see if the status register has bit 8 set.

Chris

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Hi Chris,

I did a simple test using the M5474EVB Lite board running dBUG ROM monitor:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 267C 0002 0000       MOVEA.L   #0x00020000,A3
0002000E: 4E71                 NOP
00020010: FBD3 4E71            WDEBUG    (A3)
00020014: 4E71                 NOP
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 4E71                 NOP
0002001C: 4E71                 NOP
0002001E: 4E4F                 TRAP      #0x0F
00020020: 4E71                 NOP
00020022: 4E71                 NOP
00020024: 4E71                 NOP

I set the PC to 0x20008 and issued "go" command.

Watching PSTCLK with oscope, it is running be default. After executing the above code, it is low.

So I'm seeing it work OK.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 9:27 AM
To: Seymour David-RA2693
Subject: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

I want to disable the PST signals, when not debugging, to reduce RF emissions. I used the following code successfully in an MCF537X project, but when I use it on a V4 processor I get an interrupt from the XLB arbiter.

csr_data       dc.w    0010110010000000b       ;CSR
                   dc.w    2,0,0                   ;PCD
...
                lea     csr_data,a0
                dc.w    1111101111010000b     ;wdebug.l a0
                dc.w    0000000000000011b

My assembler doesn't support wdebug, hence the hand coded dc.w stuff. All the code does is set the PCD bit in the BDM CSR register.

The fault address is csr_data + 4, i..e. half way through the data. The fault is a slave error acknowledge. The data is correctly aligned on a four byte boundary and is certainly accessible by normal instructions.

Anybody know what is going on here?

TIA, Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list. coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T15:22:36Z

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Ouch...just got everything put away! That serves me right for once trying to keep a clean office. Lesson learned. Thx!!

Ok...re-ran with following code:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 207C 0002 0000       MOVEA.L   #0x00020000,A0
0002000E: 4E71                 NOP
00020010: 4E71                 NOP
00020012: FBD0 0003            WDEBUG    (A0)

00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 227C 1000 0248       MOVEA.L   #0x10000248,A1
00020020: 2211                 MOVE.L    (A1),D1

00020022: 4E71                 NOP
00020024: 4E71                 NOP
00020026: 4E4F                 TRAP      #0x0F
00020028: 37FE                 DC.W      0x37FE
dBUG> rm pc 20008
dBUG> go
dBUG> rd
PC: 00020028 SR: 2004 [t.Sm.000...xnZvc]
An: 00020000 10000248 00000000 00000000 00000000 00000000 00000000 03FFFFF8
Dn: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dBUG>

Register D1 is zero so bit 8 is not setting.

Anything else for me to try?

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 4:11 PM
To: Seymour David-RA2693
Subject: Re: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

Hi David,
Yes I think it kills my PSTCLK, but why does it generate an XLB interrupt? Can you look at the XLB registers as see if the status register has bit 8 set.

Chris

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Hi Chris,

I did a simple test using the M5474EVB Lite board running dBUG ROM monitor:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 267C 0002 0000       MOVEA.L   #0x00020000,A3
0002000E: 4E71                 NOP
00020010: FBD3 4E71            WDEBUG    (A3)
00020014: 4E71                 NOP
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 4E71                 NOP
0002001C: 4E71                 NOP
0002001E: 4E4F                 TRAP      #0x0F
00020020: 4E71                 NOP
00020022: 4E71                 NOP
00020024: 4E71                 NOP

I set the PC to 0x20008 and issued "go" command.

Watching PSTCLK with oscope, it is running be default. After executing the above code, it is low.

So I'm seeing it work OK.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 9:27 AM
To: Seymour David-RA2693
Subject: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

I want to disable the PST signals, when not debugging, to reduce RF emissions. I used the following code successfully in an MCF537X project, but when I use it on a V4 processor I get an interrupt from the XLB arbiter.

csr_data       dc.w    0010110010000000b       ;CSR
                   dc.w    2,0,0                   ;PCD
...
                lea     csr_data,a0
                dc.w    1111101111010000b     ;wdebug.l a0
                dc.w    0000000000000011b

My assembler doesn't support wdebug, hence the hand coded dc.w stuff. All the code does is set the PCD bit in the BDM CSR register.

The fault address is csr_data + 4, i..e. half way through the data. The fault is a slave error acknowledge. The data is correctly aligned on a four byte boundary and is certainly accessible by normal instructions.

Anybody know what is going on here?

TIA, Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

RE: wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T14:46:23Z

Ouch...just got everything put away! That serves me right for once trying to keep a clean office. Lesson learned. Thx!!

Ok...re-ran with following code:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 207C 0002 0000       MOVEA.L   #0x00020000,A0
0002000E: 4E71                 NOP
00020010: 4E71                 NOP
00020012: FBD0 0003            WDEBUG    (A0)
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 227C 1000 0248       MOVEA.L   #0x10000248,A1
00020020: 2211                 MOVE.L    (A1),D1
00020022: 4E71                 NOP
00020024: 4E71                 NOP
00020026: 4E4F                 TRAP      #0x0F
00020028: 37FE                 DC.W      0x37FE
dBUG> rm pc 20008
dBUG> go
dBUG> rd
PC: 00020028 SR: 2004 [t.Sm.000...xnZvc]
An: 00020000 10000248 00000000 00000000 00000000 00000000 00000000 03FFFFF8
Dn: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dBUG>

Anything else for me to try?

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 4:11 PM
To: Seymour David-RA2693
Subject: Re: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

Hi David,
Yes I think it kills my PSTCLK, but why does it generate an XLB interrupt? Can you look at the XLB registers as see if the status register has bit 8 set.

Chris

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Hi Chris,

I did a simple test using the M5474EVB Lite board running dBUG ROM monitor:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 267C 0002 0000       MOVEA.L   #0x00020000,A3
0002000E: 4E71                 NOP
00020010: FBD3 4E71            WDEBUG    (A3)
00020014: 4E71                 NOP
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 4E71                 NOP
0002001C: 4E71                 NOP
0002001E: 4E4F                 TRAP      #0x0F
00020020: 4E71                 NOP
00020022: 4E71                 NOP
00020024: 4E71                 NOP

I set the PC to 0x20008 and issued "go" command.

Watching PSTCLK with oscope, it is running be default. After executing the above code, it is low.

So I'm seeing it work OK.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 9:27 AM
To: Seymour David-RA2693
Subject: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

I want to disable the PST signals, when not debugging, to reduce RF emissions. I used the following code successfully in an MCF537X project, but when I use it on a V4 processor I get an interrupt from the XLB arbiter.

csr_data       dc.w    0010110010000000b       ;CSR
                   dc.w    2,0,0                   ;PCD
...
                lea     csr_data,a0
                dc.w    1111101111010000b     ;wdebug.l a0
                dc.w    0000000000000011b

My assembler doesn't support wdebug, hence the hand coded dc.w stuff. All the code does is set the PCD bit in the BDM CSR register.

The fault address is csr_data + 4, i..e. half way through the data. The fault is a slave error acknowledge. The data is correctly aligned on a four byte boundary and is certainly accessible by normal instructions.

Anybody know what is going on here?

TIA, Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T14:11:28Z

Hi David,
Yes I think it kills my PSTCLK, but why does it generate an XLB interrupt? Can you look at the XLB registers as see if the status register has bit 8 set.

Chris

2009/4/7 Seymour David-RA2693 <David.Seymour@...>

Hi Chris,

I did a simple test using the M5474EVB Lite board running dBUG ROM monitor:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 267C 0002 0000       MOVEA.L   #0x00020000,A3
0002000E: 4E71                 NOP
00020010: FBD3 4E71            WDEBUG    (A3)
00020014: 4E71                 NOP
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 4E71                 NOP
0002001C: 4E71                 NOP
0002001E: 4E4F                 TRAP      #0x0F
00020020: 4E71                 NOP
00020022: 4E71                 NOP
00020024: 4E71                 NOP

I set the PC to 0x20008 and issued "go" command.

Watching PSTCLK with oscope, it is running be default. After executing the above code, it is low.

So I'm seeing it work OK.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 9:27 AM
To: Seymour David-RA2693
Subject: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

I want to disable the PST signals, when not debugging, to reduce RF emissions. I used the following code successfully in an MCF537X project, but when I use it on a V4 processor I get an interrupt from the XLB arbiter.

csr_data       dc.w    0010110010000000b       ;CSR
                   dc.w    2,0,0                   ;PCD
...
                lea     csr_data,a0
                dc.w    1111101111010000b     ;wdebug.l a0
                dc.w    0000000000000011b

My assembler doesn't support wdebug, hence the hand coded dc.w stuff. All the code does is set the PCD bit in the BDM CSR register.

The fault address is csr_data + 4, i..e. half way through the data. The fault is a slave error acknowledge. The data is correctly aligned on a four byte boundary and is certainly accessible by normal instructions.

Anybody know what is going on here?

TIA, Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

RE: wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T13:52:43Z

Hi Chris,

I did a simple test using the M5474EVB Lite board running dBUG ROM monitor:

dBUG> di 20000
00020000: 2C80                 MOVE.L    D0,(A6)
00020002: 0002                 DC.W      0x0002
00020004: 0000                 DC.W      0x0000
00020006: 0000                 DC.W      0x0000
00020008: 267C 0002 0000       MOVEA.L   #0x00020000,A3
0002000E: 4E71                 NOP
00020010: FBD3 4E71            WDEBUG    (A3)
00020014: 4E71                 NOP
00020016: 4E71                 NOP
00020018: 4E71                 NOP
0002001A: 4E71                 NOP
0002001C: 4E71                 NOP
0002001E: 4E4F                 TRAP      #0x0F
00020020: 4E71                 NOP
00020022: 4E71                 NOP
00020024: 4E71                 NOP

I set the PC to 0x20008 and issued "go" command.

Watching PSTCLK with oscope, it is running be default. After executing the above code, it is low.

So I'm seeing it work OK.

Regards,

David

David E Seymour

http://www.freescale.com/coldfire

From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of nop head
Sent: Tuesday, April 07, 2009 9:27 AM
To: Seymour David-RA2693
Subject: [ColdFire] wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

I want to disable the PST signals, when not debugging, to reduce RF emissions. I used the following code successfully in an MCF537X project, but when I use it on a V4 processor I get an interrupt from the XLB arbiter.

csr_data       dc.w    0010110010000000b       ;CSR
                   dc.w    2,0,0                   ;PCD
...
                lea     csr_data,a0
                dc.w    1111101111010000b     ;wdebug.l a0
                dc.w    0000000000000011b

My assembler doesn't support wdebug, hence the hand coded dc.w stuff. All the code does is set the PCD bit in the BDM CSR register.

The fault address is csr_data + 4, i..e. half way through the data. The fault is a slave error acknowledge. The data is correctly aligned on a four byte boundary and is certainly accessible by normal instructions.

Anybody know what is going on here?

TIA, Chris

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list. coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

wdebug instruction causes XLB slave error acknowledge interrupt on MCF547X.

2009-04-07T07:27:04Z

GPIO interrupt in ColdFier Lite

2009-03-28T01:42:11Z

Dear All

Does Any one had worked on Cold Fire lite TCPIP stack (MCF52235)along
with GPIO interrupt IRQ1 through IRQ15

regards
Sanjay Morab
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Re: vsprintf

2009-03-26T08:57:03Z

Also dietlibc (GPL), uClibc (LGPL) and the various *BSD system's libc's.

On Thu, Mar 26, 2009 at 11:30 AM, David Brown <david@...> wrote:

Granville Gregg wrote:
>

Hi

Anyone know where I can get the source for vsprintf for the GCC compiler I am in need of it for a project based on U-Boot for the MCF54450

What I am exactly looking for is standard libraries written in C which would give me support for printing of doubles (i.e. atof, vsprintf with %f, etc..). I need the C source code so I can drop it into our current embedded system

Gregg

gcc doesn't have a vsprintf function - that's part of the C library, not the C compiler. So you want to look in the source code for a C library. Different C libraries have different licenses - you cannot take the vsprintf code from the gnu libc and paste it into your code unless your entire code is (L)GPL. An alternative source that might be a better choice is newlib (BSD-style license).

mvh.,

David
---

coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

--
====
Q. How many Prolog programmers does it take to change a lightbulb?
A. No.
coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: vsprintf

2009-03-26T08:30:37Z

Granville Gregg wrote:
>

> Hi
>
> Anyone know where I can get the source for vsprintf for the GCC compiler
> I am in need of it for a project based on U-Boot for the MCF54450
>
>
>
> What I am exactly looking for is standard libraries written in C which
> would give me support for printing of doubles (i.e. atof, vsprintf with
> %f, etc..). I need the C source code so I can drop it into our current
> embedded system
>
>
> Gregg
>

gcc doesn't have a vsprintf function - that's part of the C library, not
the C compiler. So you want to look in the source code for a C library.
Different C libraries have different licenses - you cannot take the
vsprintf code from the gnu libc and paste it into your code unless your
entire code is (L)GPL. An alternative source that might be a better
choice is newlib (BSD-style license).

mvh.,

David
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Re: vsprintf

2009-03-26T08:17:40Z

Gregg,

I am not familiar with your development environment,
but, support of printing "double" is part of ANSI C standard. GCC compiler is ANSI C compliant.

See, for example, http://www.cplusplus.com/reference/clibrary/cstdio/vsprintf.html

Regards,
Yevgeni Tunik
+972-52-448-9271 (mobile phone)
___________________________________

--- On Thu, 3/26/09, Granville Gregg <ggranville@...> wrote:

> From: Granville Gregg <ggranville@...>
> Subject: [ColdFire] vsprintf
> To: "Yevgeni Tunik" <yevgeni_tunik@...>
> Date: Thursday, March 26, 2009, 4:06 PM
>
> Hi
>
> Anyone know where I can get the source
> for vsprintf for the
> GCC compiler I am in need of it for a project based on
> U-Boot for the MCF54450
>
> What I am exactly looking for is standard libraries written in C which
> would give me support for printing of doubles (i.e. atof,
> vsprintf with %f,
> etc..). I need the C source code so I can drop it
> into our current
> embedded system
>
> Gregg
>

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

vsprintf

2009-03-26T07:06:26Z

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: ****: 4.344000 From3consonants=0.3, To: repeats address as real name=0.4, X-Verify-SMTP present=0.6, Aspam=3.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

Anyone know where I can get the source for vsprintf for the GCC compiler I am in need of it for a project based on U-Boot for the MCF54450

What I am exactly looking for is standard libraries written in C which would give me support for printing of doubles (i.e. atof, vsprintf with %f, etc..). I need the C source code so I can drop it into our current embedded system

Gregg

Gregg GRANVILLE

Hardware Engineering Manager

-------------------------------------------------------

Tel 1 603.622.0212 / Fax 1 603.623.5623

ggranville@... / www.metronics.com

-----------------------------------------------------------------------------------------

METRONICS /// 30 Harvey Road // Bedford, NH 03110-6818 / US

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

ADC Sync pins on MCF52223 - where are they?

2009-03-11T23:25:54Z

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: ****: 4.900000 From3consonants=0.3, Accept Orbs.0, X-Verify-SMTP present=0.6, Aspam=2.0, spaces.live.com url=3.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

I'm looking at using the MCF52223 and wanted to use a timer to kick of a set of ADC conversions.

The MCF52223 datasheets, ADC chapter block diagram shows a SYNCx signal and then the description says that a conversion can be initiated by asserting a positive edge on SYNC0 input.

If I search for SYNC0 there is no such pin. The language makes me believe that this should be a pin.

In the signals section, the ADC Signals section talks about ADC Sync Inputs and calls them SYNCA / SYNCB <- huh? what happened to SYNC0?

So, for the longest time, I thought that SYNCA and SYNCB must be the ADC sync inputs until just a few minutes ago, when I came across a SYNCn set of signals in the General Purpose Timer section and this section refers to SYNCA and SYNCB for synchronization of the timer counter.

I'd love to know:
* Do the ADCs have sync inputs?
* If so, what are they called and what are their pin #s for the 100 pin QFP package?

Is there updated documentation around this?

Thanks,
Harjit
PS: The MCF52223 Reference manual talks about CANTX and CANRX and those don't exist on the MCF52223...

Windows Live™ Contacts: Organize your contact list. Check it out. coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

RE: Can a 3.3v input handle 5v?

2009-03-11T14:44:50Z

The MCF528x is actually the *only* ColdFire microcontroller that has 5V
tolerant inputs.

See the 'Absolute Maximum Ratings' table in the electricals - symbol
VIN. The footnote discusses limiting of current.

Regards,
Chris Nappi

-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...]
On Behalf Of Bob Furber
Sent: Wednesday, March 11, 2009 4:26 PM
To: Nappi Chris-RA5809
Subject: [ColdFire] Can a 3.3v input handle 5v?

I am having difficulty finding out if a 3.3v input can handle 5v on a
MCF5282 DMA Timer pin used as an input?

Would there be clipping diodes? If so, then one would need some
protection resistors to limit current input?

Thanks,

Bob Furber

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Can a 3.3v input handle 5v?

2009-03-11T14:26:23Z

I am having difficulty finding out if a 3.3v input can handle 5v on a
MCF5282 DMA Timer pin used as an input?

Would there be clipping diodes? If so, then one would need some
protection resistors to limit current input?

Thanks,

Bob Furber

---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

Re: MCF547X bus error

2009-03-11T08:37:54Z

I take it all back!

The XL Bus timeouts catch any gaps in the memory map. They terminate the cycle and can give an interrupt. It was just the default timeout value is about 16 seconds so I thought it wasn't working.

It seems the CPU will only hang if you have a flex bus chip select configured for external termination and nothing provides TA.

2009/3/11 nop head <nop.head@...>

Well yes I could have a power of two separate regions but not in a way that could fill all the gaps in my memory map.

I could also remove gaps by letting memories mirror, but then errant memory accesses would just go undetected. A big step backwards from where we were 20 years ago.

2009/3/11 Allon Stern <Allon.Stern@...>

On Mar 11, 2009, at 8:52 AM, nop head wrote:

Dave,
Sorry, my last reply was rubbish. The spare chip select will of course terminate the cycle, but only for one duff region.

Chris

Is this true? On the 5282 you define a chip select's base address and mask. You can define a large region and a discontiguous mask to define multiple regions for one chip select.

-
allon
---

coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: MCF547X bus error

2009-03-11T06:22:55Z

Well yes I could have a power of two separate regions but not in a way that could fill all the gaps in my memory map.

I could also remove gaps by letting memories mirror, but then errant memory accesses would just go undetected. A big step backwards from where we were 20 years ago.

2009/3/11 Allon Stern <Allon.Stern@...>

On Mar 11, 2009, at 8:52 AM, nop head wrote:

Dave,
Sorry, my last reply was rubbish. The spare chip select will of course terminate the cycle, but only for one duff region.

Chris

Is this true? On the 5282 you define a chip select's base address and mask. You can define a large region and a discontiguous mask to define multiple regions for one chip select.

-
allon
---

coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: MCF547X bus error

2009-03-11T06:12:17Z

On Mar 11, 2009, at 8:52 AM, nop head wrote:

> Dave,
> Sorry, my last reply was rubbish. The spare chip select will of
> course terminate the cycle, but only for one duff region.
>
> Chris

Is this true? On the 5282 you define a chip select's base address and
mask. You can define a large region and a discontiguous mask to
define multiple regions for one chip select.

-
allon
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.