From: Thomas B. <Wie...@gm...> - 2005-11-28 16:34:53
|
Dear Mr. Kissinger, it seems that you Controller support only 64 k in Total (RAM+ROM) and it is configured like 32+32. In this way it doesn't matter what you switch in SDCC. The manufactor describe only what is maximum possible. For your solution please refer the manufactor description how to configure Memory to 48k +16k for example. I hope it could help Best regards Thomas Boje |
From: Mike R. <mr...@fu...> - 2005-11-30 12:16:04
|
Hello all: My two cents: I have been working with the SDCC compiler using the DS80C390 and C400 port for almost a year now. I have found that almost every time I think there is a bug in the compiler, I usually find that its something I am doing wrong. The best thing I have found to do is to dig as deeply as possible to find the problem, namely using the gorgeous .map, .mem, and .rst listings the linker provides to get the overall picture of what is getting linked where and what resources are being used. Also you can get right down to the nitty gritty of what the processor is doing at every step by looking at the assembly SDCC generates (.lst is the unlinked assembly, .rst contains the addresses the code is linked to). Unless something is electrically wrong with the board or micro, the micro will execute exactly what is in the listings. The only time I have had problems crossing boundary's has been >64k, which the linker correctly generates the the extended address information, but it has to be sorted because the linker will jump back and forth between addresses (which caused my boot loader to erase a partially written section of the flash). I have crossed >32k a zillion times with no problems. Some other things to try would be to verify that the .hex file you are loading is actually being loaded in its entirety (i.e. a checksum matches for the .hex file and what's loaded in the flash) or just compare the code above 32k manually to rule out electrical problems. Is the boot loader built in or is it being programmed externally? Somehow you need to verify the .hex is being programmed in its entirety and being correctly read out. This will eliminate electrical problems. The world of embedded programming is a tricky place compared to PC programming. You have to get down to the basic level sometimes (digging through assembly listings, running things through logic analyzers) to figure out what is going on because you don't have a nice pretty monitor printing out on the screen what is going on, but have to fight using LED's and serial port output if you are lucky. I have only been doing this for about a year and a half now, but through a lot of trial and imagination I have solved every problem that I thought was something wrong with the compiler. SDCC is a very good compiler, and I think at this point most bugs are very subtle and not this obvious. If you have some specific questions I would be more than happy to help. I am not as much a veteran as most of the people on this list but I can offer all that I know. You can send me code snippets or whatever will help. This is the end of my rant I have to get back to work!! :) |
From: Tom <to...@im...> - 2005-11-30 13:25:09
|
Hello Mike, Could you help me how did you compile the DS80C390 Startup code with SDCC? I asked such question the 2005-Nov-24 titled: "DS80C390 Startup code" but no none answered yet. Best regards, Tom. |
From: Tipe D. <sdc...@di...> - 2005-11-29 10:12:24
|
Hello Thomas, Not according to the W78E516Bg.pdf data sheet I have here it doesn't! 64K of flash it says; in fact it seems to have an additional 4K loader flash too - i.e 68KB total. Scanning through the data sheet it not immediately apparent that there is any way of sectioning the main 64K flash (what they call APROM), only switching it out en block. Rather sounds like a problem with flashing the code, something hanging on A15 - that sort of thing. Or even a u/s chip maybe? Experiment... Regards *J* Monday, November 28, 2005, 9:27:47 AM, you wrote: TB> Dear Mr. Kissinger, TB> it seems that you Controller support only 64 k in Total (RAM+ROM) and it is TB> configured like 32+32. In this way it doesn't matter what you switch in TB> SDCC. The manufactor describe only what is maximum possible. For your TB> solution please refer the manufactor description how to configure Memory to TB> 48k +16k for example. TB> I hope it could help TB> Best regards TB> Thomas Boje TB> ------------------------------------------------------- TB> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files TB> for problems? Stop! Download the new AJAX search engine that makes TB> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! TB> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click TB> _______________________________________________ TB> Sdcc-user mailing list TB> Sdc...@li... TB> https://lists.sourceforge.net/lists/listinfo/sdcc-user -- Best regards, Tipe mailto:sdc...@di... |
From: Richard E. <ed...@id...> - 2005-12-01 05:42:23
|
Sadly, while this might have been a handy explanation for the problem, it's not the case. The 89C420 supports 64KB of external program space and 64KB of external data space in addition to its 16K of internal (FLASH) program space, 256 bytes of normal internal RAM and 1KB of XRAM, mappable into either program or data space. The 89C430 has a similar memory map, while the 89C440 has 32KB of internal (FLASH) program space and the 89C450 has 64KB of internal (FLASH) program space. There must be some other explanation. regards, Richard Erlacher ----- Original Message ----- From: "Thomas Boje" <Wie...@gm...> To: <sdc...@li...> Sent: Monday, November 28, 2005 2:27 AM Subject: [Sdcc-user] Re: 8051 64K problem > Dear Mr. Kissinger, > it seems that you Controller support only 64 k in Total (RAM+ROM) and it > is > configured like 32+32. In this way it doesn't matter what you switch in > SDCC. The manufactor describe only what is maximum possible. For your > solution please refer the manufactor description how to configure Memory > to > 48k +16k for example. > I hope it could help > Best regards > Thomas Boje > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Frieder F. <fri...@we...> - 2005-12-01 08:15:15
|
Richard Erlacher wrote: > There must be some other explanation. You'll find it in another thread: http://sourceforge.net/mailarchive/forum.php?thread_id=9108730&forum_id=4107 |
From: Richard E. <ed...@id...> - 2005-12-01 15:50:30
|
Yes, I see that. In fact, I saw it before, but, not being clever enough to recognize such details, I missed the point. Thanks. BTW, is there a DOS-based 'C' compiler that uses more or less the same syntax as SDCC? I'd like to be able to work on the code on the pC without having to rewrite it when moving to SDCC. regards, Richard Erlacher ----- Original Message ----- From: "Frieder Ferlemann" <fri...@we...> To: <sdc...@li...> Sent: Thursday, December 01, 2005 1:14 AM Subject: Re: [Sdcc-user] Re: 8051 64K problem > Richard Erlacher wrote: >> There must be some other explanation. > > You'll find it in another thread: > http://sourceforge.net/mailarchive/forum.php?thread_id=9108730&forum_id=4107 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |