[SOLVED] using internal and external program memory with C compiled code

Status
Not open for further replies.

cgchas

Member level 3
Joined
Jul 19, 2011
Messages
56
Helped
2
Reputation
8
Reaction score
4
Trophy points
1,288
Activity points
2,001
I've added 30K flash memory to a single board computer (at89s52, 32K SRAM, 2 82c55's, etc). I can read from and write bytes to the flash memory. I am using SDCC for hex code generation.

What I want to do is compile C functions and data suitable for placement onto the flash memory for internal and external program execution, but I am not sure how exactly so that there will be proper linkage with code executed from program memory internal to the AT89S52. In other words I want to execute from both internal and external flash memory using C compiled code.

I realize I could copy the entire hex file to external flash and wire the EA pin to GND for external program fetches, but that isn't exactly what I want to do if I do not have to. I would like to perform all self-test routines from the internal 8K of the AT89S52 and branch to my application in external code memory after the self-tests have completed.

Any help would be greatly appreciated.

Charles
 

The AT89S52 uses 8k of internal code memory but if you use addresses above it and the memory is physically present, it will automatically jump to execute program from the external code memory .. in the external code memory don’t use the first 8k ..

Don’t use lock bits as they will interfere with fetching code bytes from internal/external memory ..

:wink:
IanP
 

Attachments

  • AT82S52 - LockBits.JPG
    44.4 KB · Views: 134


Hello and thank you for your reply.

Yes, I am aware that if I wire EA to VCC, program code fetches for addresses higher than 0x2000 (> 8K) will be from external memory, but my question is how do I organize C compiled code onto internal and external memory?

I know how to do all internal program memory or all external program memory, but how does one tell the compiler to split up code that will have parts that reside in both?

I guess my concerns are with regards to linkage, but there may be other issues that I am not yet aware.

Charles
 

Splitting the intel hex file with srecord was the perfect solution.
 

I just read your thread for the first time. I'm not familiar with the capabilities of the SDCC compiler package. Did you attempt to divide the HEX file into parts using the linker?
 

I just read your thread for the first time. I'm not familiar with the capabilities of the SDCC compiler package. Did you attempt to divide the HEX file into parts using the linker?

No, but I did ask if SDCC was capable of such a thing to the sdcc-user mailing list and the response was to have a look at srecord.

In other words, I do not believe SDCC has the capability to perform an address-range-based split on its own.

For my case, the desired split is based on two ranges: 0x0000 - 0x1FFF (8K AT89S52 internal flash), and 0x8000 - 0xF7FF (30K external flash), which leaves me 0xF800 - 0xFFFF (8x 256 byte ranges for use with externally addressed peripherals such as the 8255).

What SDCC can do is set the program memory location, so if for example I wanted to place the entire hex at 0x8000 I would pass --code-loc 0x8000 to the linker.

As far as other capabilities of SDCC and the AT89S52, so far SDCC has exceeded my expectations.

Charles
 
Last edited:
As far as other capabilities of SDCC and the AT89S52, so far SDCC has exceeded my expectations.

Thanks Charles,

I appreciate the info. I've been meaning to download the SDCC package and give it a try. It's always nice to have an open source option, especially when you're in a pinch.

Have you used SDCC with any other MCUs besides the AT89S52?

BigDog
 

Thanks Charles,
I appreciate the info. I've been meaning to download the SDCC package and give it a try. It's always nice to have an open source option, especially when you're in a pinch.
BigDog
I agree. I am most grateful for open source projects such as: sdcc, srecord, avrdude, usbasp, v-usb, libusb, and winavr.

Have you used SDCC with any other MCUs besides the AT89S52?
BigDog

I have not personally, but I know that several other targets are supported including pic14devices - 14 bit 16Fxxx / 16Cxxx / 12Fxxx series and pic16devices. There are a few others as well.

For AVR targets I use WinAVR.

For programming over USB I use an ATMEGA8 to program the AT89S52. I use this circuit (USBASP):
USB 8051/AVR programmer - Free 8051 Microcontroller projects

which I use with the app, AVRDUDE:
AVR Downloader/UploaDEr - Summary [Savannah]

For PC Parallel Port programming, I use this cable:
**broken link removed**
which is the same as the AEC_ISP pinout which also works with AVRDUDE, you just have to add the AEC_ISP pinout to the avrdude.conf.

The software I use for parallel port programming is ISPProg 1.2.0.55:
ISP Programmer | Adam's Site

I have successfully programmed AT89S52s and ATMEGA8s with ISPProg as well as brought back to life an ATMEGA8 whose fuses were programmed improperly. (this required my external PWM at 16KHz). I have found ISPProg to be very reliable.

Lastly, I program the external flash SST39SF010A via serial uart via the AT89S52. I am currently working on my own serial interface parallel programmer for programming a few of the external flash chips that I have. (SST39SF010A and AM29F010)

My next project will be to modify one of the boilerplates from:
V-USB - A Firmware-Only USB Driver for Atmel AVR Microcontrollers
to program the external flash chips via USB 1.1.

The final programmer will be able to program using an ATMEGA8 running V-USB to Atmel chips such as the AT89S52s ISP, PC Parallel Port to Atmel ISP, and finally ATMEGA8 running V-USB to the UART of the AT89S52 to external flash. The USB 1.1 programming seems a bit slower than direct PC parallel port, but its cool to be able to accomplish this much using open source software.

Charles
 
Last edited:
Yes, that is a nice utility.

Fifteen years ago, I was doing it by hand for 4-Gang or 8-Gang EPROMs.
 

Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…