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


2009/7/4 Bodo Wenzel <bodowenzel@web.de>
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.


Sdcc-user mailing list