TI E2E Community
Stellaris® ARM® Microcontrollers
Stellaris® ARM® LM3S Microcontrollers Forum
EPI problems with the LM3S9D92
I am using the LM3S9D92 eval kit with CCS5. I am trying to use the EPIO on the controller, however I see no activity on the ALE (EPIOS30, PJ6), the WE (EPIOS29, PJ5), or the A1 (EPIOS1, PH2) lines.
The set-up code is
#define EPI_PORTC_PINS (GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_6 | GPIO_PIN_7)
#define EPI_PORTE_PINS (GPIO_PIN_0 | GPIO_PIN_1)
#define EPI_PORTF_PINS (GPIO_PIN_4 | GPIO_PIN_5)
#define EPI_PORTG_PINS (GPIO_PIN_0 | GPIO_PIN_1)
#define EPI_PORTH_PINS (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3 | \
GPIO_PIN_4 | GPIO_PIN_5)
#define EPI_PORTJ_PINS (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3 | \
GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_6)
#define MEM_START_ADDRESS 0X000000
EPIConfigHB16Set(EPI0_BASE, EPI_HB16_MODE_ADMUX | EPI_HB16_WRWAIT_0 | \
EPI_HB16_RDWAIT_0 | \
EPIAddressMapSet(EPI0_BASE, EPI_ADDR_RAM_SIZE_16MB |EPI_ADDR_RAM_BASE_6);
MEM_ADDR_PTR = (unsigned long *)0x60000000;
The code to do the operation is
unsigned long z;
GPIOPinWrite(GPIO_PORTE_BASE, GPIO_PIN_4, 0x10);
if (count < Samp)
ADCSequenceDataGet(ADC0_BASE, 3, z);
MEM_ADDR_PTR[MEM_START_ADDRESS + count] = z;
GPIOPinWrite(GPIO_PORTE_BASE, DSP_SENSOR_PINS, 0x00);
GPIOPinWrite(GPIO_PORTE_BASE, GPIO_PIN_4, 0x00);
Everything seems to work except the EPIO.
Thre must be something in the project configuration, or something I'm not enabling, or something I'm not setting. I download you *.bin using LMFlashProgrammer, all the lines toggle. Your image works. Also, I tried a version with a SDRAM EPIO configuration, and the refresh writes are there, but nothing else; no address lines, etc. So, there must be something in my configuration or initialization files.
Can you send me a copy of the c-code you used for the EPIO test? Maybe there is something you are automatically adding (since it must obviously be there), that I don't have included, or don't know to add. What ever you did works.
I put the source file in the ZIP linked to this post.
I compiled your code, and it works. I get the signals. I checked my code against yours, line-by-line, word-by-word, and mine didn't work. The only difference I could see was that you had all your code in one file. I split the initializations and header file into separate files.
I generated a new project with my code, but this time put everything in one file, and it works.
Is it possible that the preprossor, compiler, or linker (or all 3) are trying to optimise something and messing it up? Is there a way to set the configuration properties to test this? I would hate to be required to put everything in one large file.
Can you put the init_CLK, init_GPIO, etc in separate files, and put the defines, and prototypes in a header file, and then compile to see if you get the same problem?
Maurice GivensIs it possible that the preprossor, compiler, or linker (or all 3) are trying to optimise something and messing it up? Is there a way to set the configuration properties to test this? I would hate to be required to put everything in one large file.
Turn off optimizations and rebuild. Common problem here is to make sure that any variable used in main line and an interrupt is declared volatile.
However, it is more likely that you have something misconfigured in your CCS project file.
Maurice GivensCan you put the init_CLK, init_GPIO, etc in separate files, and put the defines, and prototypes in a header file, and then compile to see if you get the same problem?
Doesn't matter if you have 1 file or 1000, as long as the compiler knows how to put them together. I do not use CCS so I can't speak specifics of that tool chain, but GCC tool chain includes tools like readelf, objdump, nm that are very useful for stuff like this. Joe can probably tell you what the analog is for CCS. If you build your "non working" project and Joe's "working" project, you can then use these tools to look at the resulting images to see what is missing in the non working version. With that info you can go back to your project file and have a pretty good idea where to look.
Also the linker should output a map file that will tell you how the image is put together. Compare the two, find the differences.
>>Turn off optimizations and rebuild. Common problem here is to make sure that any variable used in main line and an interrupt is declared volatile.
That was already done.
>>Doesn't matter if you have 1 file or 1000
Obviously it does!
>>it is more likely that you have something misconfigured in your CCS project file.
This was my original question after I was able to get things to work by putting everything in 1 file. The question is what in the configuration file needs to be set/changed/unset/modified to cure this problem. If the files are separated and compiled, is the problem repeatd at TI? For now, the only work-around I have is putting everything in 1 file.
Maurice GivensThat was already done.
Then why ask the question if the first place?
Maurice Givens If the files are separated and compiled, is the problem repeatd at TI? For now, the only work-around I have is putting everything in 1 file.
It would be nice if TI had the resources to test everyone's project who is having problems, but that is quite an onus on them, yes? My only point being that there are things you could be doing to figure this out on your own. Putting everything in one file is a work around, but you do have the option to dig into the working and non-working images, finding out whats wrong, and fixing the problem in lieu of a applying band aid. A lot more work? sure - the first time, but you'll certainly understand how your code goes together much better:)
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.