From: Bart <lem...@gm...> - 2009-07-02 13:15:15
|
Hi all, -- System specs: Ubuntu Jaunty Jackelope 9.04 (Linux 2.6.28-13-generic), SDCC 2.9.0 #5416 Target processor: ADuC832 8051 compatible -- Problem: I have a pointer to an unsigned char, i put a char into the variable the pointer is pointing to, push it to some outputs and nothing happens.... Example code: ... unsigned char * stream; stream = (unsigned char *) malloc(1); if(stream == NULL) return NULL; *stream = (unsigned char) getchar(); // getchar returns just a char P2 = *stream; ... Nothing apears on the output port P2... It has something to do with the pointer thats for sure, the assembly code is correct and if i replace the getchar function by a value it doesnt work either... It looks like i just cant write a value to the variable the pointer is pointing to. Now the following for example works: unsigned char stream = 0xaa; // just an example value P2 = stream; Any thoughts? Cheers Bart |
From: Bodo W. <bod...@we...> - 2009-07-03 06:25:55
|
> if(stream == NULL) > return NULL; Are you sure that malloc() returned a valid pointer? For debugging I would change this code into: if (stream == NULL) { P2 = 0xAA; return NULL; } Or, as I know assembler, I would look into the machine code to check it does The Right Thing(TM). HTH, Bodo |
From: Bart <lem...@gm...> - 2009-07-03 07:49:02
|
Yes the malloc is ok. NULL is defined as (void *) 0 and that's not the content of stream, i did your test and he didn't put 0xaa on the output. For example: if(stream == NULL) { P2 = 0xaa; } else { P2 = 0xf0; } gives 0xf0 on the output Even the simplest main with malloc fails: void main(void) { unsigned char * stream; stream = (unsigned char *) malloc(1); if(stream == NULL) { P2 = 0xf0; } else { *stream = 0xaa; P2 = *stream; } } Gives nothing on the output port P2 I also took a look at the assembly file and it looks fine to me for all my test programs. I see that he loads 1 in the dptr, probably the 1 byte i want to allocate with malloc, then he lcall's the subroutine _malloc, then he moves the 3 byte address in r2, r3, r4. then the NULL check is nothing more than 3 times a compare and jump not equal on 0 value followed by placing 0xf0 on P2 like it should be. In the other case i see that the pointer address is loaded, followed by putting 0xaa in the accumulator followed by an lcall to __gptrput like it should be. Then the pointer address is moved again in the registers followed by a lcall to __gptrget and a move of the accumulator to P2 since __gptrget stocks his result in the accumulator. ; main.c:12: test = (unsigned char *) malloc(1); mov dptr,#0x0001 lcall _malloc mov r2,dpl mov r3,dph mov r4,#0x00 ; main.c:13: if(test == NULL) cjne r2,#0x00,00102$ cjne r3,#0x00,00102$ cjne r4,#0x00,00102$ ; main.c:15: P2 = 0xf0; mov _P2,#0xF0 sjmp 00105$ 00102$: ; main.c:19: *test = 0xaa; mov dpl,r2 mov dph,r3 mov b,r4 mov a,#0xAA lcall __gptrput ; main.c:20: P2 = *test; mov dpl,r2 mov dph,r3 mov b,r4 lcall __gptrget mov _P2,a It makes no sense to me, the only thing i can think of is that the compiler doesnt make the right hex file for loading in my µc... Still thanks for the reply. 2009/7/3 Bodo Wenzel <bod...@we...> > > if(stream == NULL) > > return NULL; > Are you sure that malloc() returned a valid pointer? > > For debugging I would change this code into: > > if (stream == NULL) { > P2 = 0xAA; > return NULL; > } > > Or, as I know assembler, I would look into the machine code to check it > does > The Right Thing(TM). > > HTH, Bodo > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Bodo W. <bod...@we...> - 2009-07-04 12:52:23
|
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 |
From: Maarten B. <sou...@ds...> - 2009-07-06 14:06:55
|
Hello Bart, I agree with Bodo. Xdata is probably not set up correctly. Does your mcu have internal xdata? And do you need to enable it? Otherwise I expect your real external ram not to be working. You should not need to initialize malloc, it's probably ok. Greets, Maarten > 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 |
From: Bart <lem...@gm...> - 2009-07-21 18:56:55
|
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 <bod...@we...> > 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Maarten B. <sou...@ds...> - 2009-07-21 20:50:41
|
Bart, 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(). Maarten > 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 <bod...@we...> > >> 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 >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> > ------------------------------------------------------------------------------ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Bart <lem...@gm...> - 2009-07-21 23:07:23
|
Maarten, 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 Bart 2009/7/21 Maarten Brock <sou...@ds...> > Bart, > > 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(). > > Maarten > > > 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 <bod...@we...> > > > >> 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 > >> Sdc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |