Hey all, I am using uVision 3 and a Phytec 2294 board. I have an external memory device connected to the phytec expansion board. The external device is using /CS0, although from talking to phytec, I am not sure if that is quite right. I have set up the external memory space in the project options like so: Start: 0x80000000 Size: 0x4 When I define a variable like :
#define volatile var x __at 0x8000000
Let's put aside any issues related to linker-located data objects and simply access memory locations directly. Take the incomplete snippet below and look at its disassembly. You should see code generated to read from those addresses. If so, then you should be able to incorporate it into a test on the actual hardware, while playing around with the BCFGn registers and probing the CSn signals on the board with a scope to look for activity.
#define ADDR_TO_P(addr) ((volatile unsigned char *)(addr)) void foo(void) { unsigned char b; for (;;) { b = *ADDR_TO_P(0x80000000); b = *ADDR_TO_P(0x81000000); b = *ADDR_TO_P(0x82000000); b = *ADDR_TO_P(0x83000000); } }
Dan, Thanks again. When I plug that code in to my program, I get the following: *** error 65: access violation at 0x80000000 : no 'read' permission *** error 65: access violation at 0x80000001 : no 'read' permission *** error 65: access violation at 0x80000002 : no 'read' permission *** error 65: access violation at 0x80000003 : no 'read' permission Is there somewhere I need ot set up access permissions?
Well, the good new is that you are no longer accessing 0x00000000. But where is this message coming from -- IDE, simulator, some kind of target OS? http://www.keil.com/support/docs/814.htm Simulator/debugger perhaps...
That last one was my fault, I didnt have those address in my memory map. After adding the ranges for those addresses, it went through the code just fine. However, when I checked the address of b, it still came back with somethign in the 0x0000000 range. Am i misunderstanding this representation? I guess my problem is to find out how to create those adddress mappings automatically, so its that way everytime i download to the chip.
"That last one was my fault, I didnt have those address in my memory map." That is something that your development/debug environment is requiring. "However, when I checked the address of b, it still came back with somethign in the 0x0000000 range. Am i misunderstanding this representation?" Sure 'b' is an auto, so has an address on the stack. We're trying to read from absolute addresses 0x80000000, 0x81000000, 0x82000000, and 0x83000000, in as simple a way as possible, into 'b' (a bit bucket) merely for the purpose of causing the hardware to perform bus transactions so you can monitor chip selects. "I guess my problem is to find out how to create those adddress mappings automatically, so its that way everytime i download to the chip." Well, there's a bit too much IDE/debugger "automagic" stuff going on here. I don't know if wizards are supposed to be writing to your BCFGn registers or if you need to do it in code. What I was trying to get at was enough "stuff" peeled away to get to the root of what configuration allows what chip select to twiddle.
Right, I saw in the help file you have to declare all memory space you are trying to use, which makes a moderate amount of sense. That is something that your development/debug environment is requiring. Sure 'b' is an auto, so has an address on the stack. We're trying to read from absolute addresses 0x80000000, 0x81000000, 0x82000000, and 0x83000000, in as simple a way as possible, into 'b' (a bit bucket) merely for the purpose of causing the hardware to perform bus transactions so you can monitor chip selects. OK, I understand that now. Maybe a good test would be to write to those addresses and then try to read from them in the simulator. I think that I will give this arest for the day though. You have been more than help ful and I really appreciate it. More or less, I wanted to make sure there was no gotchas that I wasnt paying attention to in code or on the hardware that would prevent me from seeing things work. I think im going to have the hardware changed to work off CS3, so I can avoid any CS0 confusion. But to recap, all I really need to do, is define a variable at an address, write/read from it, and the chip select should take care of assert the proper signal. I think that is it, let me know if I am over simplifying :) Thanks again dan Doug
"But to recap, all I really need to do, is define a variable at an address, write/read from it, and the chip select should take care of assert the proper signal." If this new address range is for a memory device, say additional RAM, defining data objects to be allocated there is a good thing. Otherwise, if the new address range is for accessing some hardware registers or the like, defining data objects to be allocated there is, in my opinion, optional and casting an address to structure pointer, union pointer, integer pointer, or whatever and then dereferencing it is equally valid. Both techniques will assert the chip select assuming that the controller registers have been properly configured. An no, you are not oversimplifying. It is simple! Regards, -- Dan Henry
Dan, When you say that creating data objects for external hardware registers is optional, how do you mean. How can I write to them or read from them, if I do not have them defined? I don't think I quite follow that line of reasoning? Thanks Doug
"When you say that creating data objects for external hardware registers is optional, how do you mean. How can I write to them or read from them, if I do not have them defined? I don't think I quite follow that line of reasoning?" I am making a distinction between using memory-allocating defining declarations for data objects (variables) and using the conventional direct access means for hardware registers. During program development you add code and data objects to your source code to implement your algorithms. You compile the code and link it to become an executable. For a simple system you supply base addresses where the linker should start allocating your code (.text), your data (.data, .bss), your stack, etc. and don't really care where the linker finally locates a particular data object -- just that you be able to access it. You let the linker allocate storage for your data objects and resolve their names to addresses. Hardware registers, on the other hand, are typically located at fixed addresses. No matter how you change your program, those hardware register addresses do not change. So it is quite conventional to not involve the linker and to use the kind of direct access means we've been talking about. For example, take a look at lpc22xx.h for your processor. Single registers have this form:
/* External Memory Controller (EMC) */ #define BCFG0 (*((volatile unsigned long *) 0xFFE00000))
typedef volatile unsigned int AT91_REG; // Hardware register definition // ***************************************************************************** // SOFTWARE API DEFINITION FOR Memory Controller Interface // ***************************************************************************** typedef struct _AT91S_MC { AT91_REG MC_RCR; // MC Remap Control Register AT91_REG MC_ASR; // MC Abort Status Register AT91_REG MC_AASR; // MC Abort Address Status Register AT91_REG Reserved0[1]; // AT91_REG MC_PUIA[16]; // MC Protection Unit Area AT91_REG MC_PUP; // MC Protection Unit Peripherals AT91_REG MC_PUER; // MC Protection Unit Enable Register } AT91S_MC, *AT91PS_MC; // ***************************************************************************** // SOFTWARE API DEFINITION FOR Real-Time Clock Alarm and // Parallel Load Interface // ***************************************************************************** typedef struct _AT91S_RTC { AT91_REG RTC_CR; // Control Register AT91_REG RTC_MR; // Mode Register AT91_REG RTC_TIMR; // Time Register AT91_REG RTC_CALR; // Calendar Register AT91_REG RTC_TIMALR; // Time Alarm Register AT91_REG RTC_CALALR; // Calendar Alarm Register AT91_REG RTC_SR; // Status Register AT91_REG RTC_SCCR; // Status Clear Command Register AT91_REG RTC_IER; // Interrupt Enable Register AT91_REG RTC_IDR; // Interrupt Disable Register AT91_REG RTC_IMR; // Interrupt Mask Register AT91_REG RTC_VER; // Valid Entry Register } AT91S_RTC, *AT91PS_RTC; #define AT91C_BASE_MC ((AT91PS_MC) 0xFFFFFF00) // (MC) Base Address #define AT91C_BASE_RTC ((AT91PS_RTC) 0xFFFFFE00) // (RTC) Base Address
"The same thing goes for new hardware you are having mapped into the 0x83000000 expansion area." Unless, of course, that hardware is memory!
Dan, Well the new hardware is just a chip with hardware addresses. So I just want to assign register 1 at 0x83000000. Then perform reads and writes to it. Thats really it :) Doug
Simple then, once you have:
#define MY_REG1 (*(volatile unsigned char *)0x83000000)
reg = MY_REG1;
MY_REG1 = val;
Dan, In the Keil targget options, there is a spot to specify external memory, do I need to specify my ranges in there as well. I am unclear on how my code knows when I say go to 0x83000000, that it actually knows how to get to that address and read from it or write to it. Doug
"In the Keil targget options, there is a spot to specify external memory, do I need to specify my ranges in there as well." That, I think, is what you did to shut up the "*** error 65: access violation" messages. Don't think of it as adding a specification for external memory, but rather for an external memory-mapped device or peripheral. Look at lpc22xx.h and you'll see that there are memory-mapped peripherals in the 0xFF------ and 0xE0------ ranges. Presumably, the IDE already has those ranges covered, but you need to tell it not to fuss about accesses to your new memory-mapped I/O area. That is an artifact of using this type of toolchain. If you were doing it all with simple command-line compile/link/load tools, you wouldn't have to mess with it. "I am unclear on how my code knows when I say go to 0x83000000, that it actually knows how to get to that address and read from it or write to it." The way we're writing it here using the MY_REG1 macro (name it what you want), the compiler can't help but generate code to do it. It's going to generate code to load a register with 0x83000000 and to then do indirect loads and stores "through" that register. Check the disassembly and you'll see.
That is an artifact of using this type of toolchain. If you were doing it all with simple command-line compile/link/load tools, you wouldn't have to mess with it. Now there you're IMHO being a bit overly negative. Fact is, with such simpler tools, you just wouldn't have a simulator to be told about the existence (or not) of memory at given addresses on the simulated hardware. Calling the need to configure each part of the toolchain, which implies that having more elements in it will mean more configuration items to fill in, an artifact doesn't do it justice.
None of my comments were intended to be negative per se. There is a very clear distinction between configuration that has to be done to keep a toolchain happy and configuration that has to be done to make the hardware work. Nothing discussed so far has cleared up whether some toolchain settings actually have an effect on the hardware. I am wasting my time trying to help with what appears to be a very simple software/hardware integration issue when there are nuances to a toolchain that I can't see which are fogging up my glasses. When I am debugging software/hardware integration issues (e.g., a chip select), I remove as many sources of extraneous unknown variables as I can. But that's just me.