It's an ADuC832 8051 compatible from Analog Devices.
I did some research about _sdcc_startup_external and read the datasheet of the controller again and inserted the following into my code:

unsigned char _sdcc_external_startup(void)
     CFG832 |= 0x01;
     return 0;

Since i enabled the LSB of that special function register, the 2k internal RAM is mapped in the XRAM space starting from address 0
When i do the following now:

unsigned char * test;
test = (unsigned char *) malloc(1);
*test = 0x05;
P2 = ~(*test); // inversion cause P2 contains leds that are powered on with a 0

I see 2 happy leds forming the binary number 5 :)
Now that's a happyness creator! :)
Thank you very much for the humangeous tip :) i just had not the experience with this things yet.

Kind regards


2009/7/21 Maarten Brock <>

Did you ever mention which mcu you're using? You say it has 2kB of
internal ram. But have you checked if you need to enable it? SDCC will not
do that for you! The best place to do it is in _sdcc_external_startup().


> Hello Bodo & Maarten
> My apologies for the very late reply, i was very busy at work with getting
> these things done but without the malloc cause i had some deadline
> pressure.
> For the moment of this mail i'm not able to look at the outputs with a
> scope
> or something so i will do that as soon as i get back in the lab at work. I
> neither have a simulator about the specific controller.
> Another problem is that i can't put the value of the pointer to my output
> LED's on P2, type mismatch he says + i can't shift a pointer, compile
> error,
> that i understand, as for as i know only + and - are allowed operations on
> pointers so i'm not sure how to view the values of the other bytes of the
> pointers.
> I don't think it's an hardware problem, i forgot to mention that in this
> case i'm only working with the internal program flash memory of my
> controller and it's internal ram.
> There is no external flash or ram connected.
> I only know he has about 62k program flash, 4k data flash, 2048 bytes ram,
> all of them are on chip.
> I don't know if i need to enable something to use the ram for malloc, as
> far
> i read in the sdcc manual, sdcc takes care of it so i didn't mind about
> that.
> Again sorry for the late reply and i will test my output pins asap and let
> you people know the results.
> Very much thx for all the replies
> Kind regards
> Bart
> 2009/7/4 Bodo Wenzel <>
>> Hi Bart,
>> Your analysis is well done, and I appreciate your assembler knowledge.
>> However, I'm not sure that I do understand what you mean by "Gives
>> nothing
>> on
>> the output port P2." For the moment I assume that each line of P2
>> doesn't
>> change its level, i.e. it stays at "1" which is the default after a
>> reset.
>> So
>> it's possible that P2 is written with 0xFF.
>> BTW, you can check such a write with a pulldown resistor that lowers the
>> voltage at a pin down to 3/4 or 1/2 of VCC. An oscilloscope will show
>> the
>> write access with a small impulse to VCC because the 8051 ports will
>> reduce
>> the builtin pullup value for two clock cycles.
>> My suggestion for the next steps would be:
>> If you can't use a simulator with the hex file, and if the only
>> watchable
>> output is P2,
>> 1. Run three tests, each setting P2 with one byte of the generic
>> pointer.
>> 2. Check that the external (or internal?) memory at that address is
>> working
>> or
>> at least should be by the schematics.
>> 3. Invert the value before assigning it to P2, like "P2 = ~*stream;" I'd
>> expect then every bit at "0".
>> If you have a simulator at hand, run the program with it. Well, you will
>> have
>> to step through the builtins, but perhaps the simulator can run a
>> subroutine
>> as one step.
>> Another issue is the malloc stuff. I'm not using SDCC currently and so I
>> don't
>> know how it works here. But I played a bit with z88dk, and there I had
>> to
>> set
>> up malloc with some special functions and variables to get it working.
>> To say it shortly, these are the two most probable reasons:
>> - The memory pointed to by the return value of malloc() can't store
>> anything
>> because of a hardware problem. So a read from it returns 0xff which can
>> be
>> the value of an open databus.
>> - malloc() returns an arbitrary but reproducable pointer because the
>> allocation management is not initialized. And the memory pointed to
>> can't
>> store any value and always returns 0xFF.
>> Bodo
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Sdcc-user mailing list
> ------------------------------------------------------------------------------
> _______________________________________________
> Sdcc-user mailing list

Sdcc-user mailing list