I am having trouble initializing the Ethernet controller to use an RxBD Ring located in the internal SRAM of the micro.. my debugger crashes everytime.
The ColdFire manual (sec 220.127.116.11) it says the Receive Descriptor Ring Start Register (ERDSR) points to the start of the circular RxBD queue "in external memory".. however I always read this to mean memory external to the FEC, not memory external to the micro.
Has anyone been able to use internal RAM for Ethernet buffer space? I know other flavours of ColdFire have no external bus and must be using this memory.. I am hoping the 5271 can be setup the same.
This is just a guess, but maybe you haven't enabled backdoor access to the SRAM? (Note: I am not an expert on this stuff, so this may be unhelpful...).
Presumably the main processor core can see the SRAM OK. This is because you have configured the RAMBAR register in your start-up code. However, this does NOT mean that other on-chip peripherals like DMA and FEC can access the SRAM too.
What you need to do is enable the backdoor SRAM access using one of the configuration registers in the System Control Module (SCM). Confusingly, this is also called RAMBAR but it is unrelated to the main RAMBAR register.You need to configure this register and set the BDE (back door enable) bit.
To quote from the MCF5271 manual:
"Do not confuse this [main] RAMBAR with the SCM RAMBAR in Section 18.104.22.168, “Memory Base Address Register (RAMBAR).” Although similar, this core RAMBAR enables core access to the SRAM memory, while the SCM RAMBAR enables peripheral (e.g. DMA and FEC) access to the SRAM".
Thanks guys. I will check out the back-door enable today. I know the SRAM is read/writeable from the main processor core, but I really hope the FEC can use it to. The code crashes on the first write to the RDAR register in the FEC, when I have the RxBD ring in SRAM. There is no crash with the BD ring in external DRAM. Writing this RDAR register triggers the FEC to fetch a descriptor which will load the SRAM address. I don't have an exception handler installed so I'm not sure where the code is going to, but CW isn't able to communicate to the micro any more. I'll post a follow up if I can get the FEC DMA to SRAM working. cheers, Joel.
Well that did it. To use internal SRAM with the FEC you need the back-door action enabled in the SCM RAMBAR.
However, even though the manual says the CPU RAMBAR and SCM RAMBAR should both be set to allow dual-port SRAM access, I did find my app working crash free when only the BDE bit in the SCM RAMBAR was enabled..
Is there a difference between enabling back-door access and setting dual-port access?
Also, after reading chapter 6 (SRAM) and chapter 11 (SCM) multiple times, I still find the description of SRAM operation lacking. They describe a dual-ported local memory and an application for double-buffering ("load data into one portion...manipulate data in another portion", ch 11). The manual also describes the SRAM as "partitioned into two physical memory arrays" (ch 6)
Does this mean the simultaneous access only works if the addresses reference different halves of the SRAM? When dual-port is enabled, do the front-door and back-door ports both have access to the entire SRAM block? Is there a DMA error if the CPU is writing to SRAM and the DMA needs access to the same address?
Maybe I should move this to a new SRAM thread as the answers to these questions may just bring more SRAM questions..
I'm not an expert on this stuff, but did you also spot the MPARK register? It allows you to configure the internal bus arbiter, which controls what happens when the core and DMA both want the bus at the same moment. It looks quite flexible.
Obvioulsy, Coldfire MCUs with no external bus are able to use on-chip SRAM with their Ethernet controller. My MCF52233-based board confirms this. If I remember correctly, some registers had to be modified in order for the FEC DMA to be able to access the on-chip SRAM. My experience tells me that in debugging wild guesses don't work most of the time. You have to use the basic debugging techniques to try and pinpoint the cause of the bug. Which instruction exactly fails? How does it fail? Presumably, it causes a CPU exception. Then, handle the exception, examine it's stack frame and decode the bit fields.