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 <bodowen...@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. > > Bodo > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user >
------------------------------------------------------------------------------
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
