From: Simon H. <Sim...@co...> - 2003-07-03 02:52:06
|
karthik bala guru: > I am into something like finding all the possible > ways to to bring a perfectly operating controller to=20 > halt(standstill) using just the coding . >=20 > I want just the ways in which a controller can > be affected or its operation distorted using > software(coding) alone. Are you trying to get modes of operation outside of what is given in the = datasheet? Like drawing excess current and desoldering itself, or what? Something like how on the 6510 (at least, the one used in the C64) would = crash if you executed the undocumented opcode 0x02? |
From: Gregory L M. <gm...@co...> - 2003-07-03 05:18:11
|
> Hi friends, > > Do throw some of your presitigous ideas for > an analysis made by me. > > I am into something like finding all the possible > ways to to bring a perfectly operating controller to > halt(standstill) using just the coding . > > I want just the ways in which a controller can > be affected or its operation distorted using > software(coding) alone. > > The software could be either in ASSEMBLY or SDCC or > KEIL. Plz brief the tricks and tell the code. > > Thanx in advance, > Xpecting ur fullest support, > karthik bala guru > li...@ya... > > clr ea ; Disable all interrupts loop: jmp loop ; Hang here FOREVER!! Or in C EA = 0; // Disable interrupts while(1); // Hang here FOREVER! Greg Montgomery gm...@co... |
From: Arnaud C. <Arn...@in...> - 2003-07-03 08:57:43
|
Hello all ! I have a big problem... I make a port of a big projet with a lot of files having a special naming convention ! Files are named like this : sourcefile.tini.c <- there is more than one dot ! or like this : path/../sourcefile.c For each file, SDCC made a sourcefile.tini.rel well. But the link doesn't work :^( It tells me: sourcefile.rel : cannot open. or path/.rel : cannot open. Here is a sample script I use : echo COMPIL sdcc -c -mds390 --model-flat24 --stack-10bit src/../src/test-tini.c # OK !! echo LINK sdcc -mds390 --model-flat24 -V --stack-10bit -Wl-r --xram-loc 0x100080 --code-loc 0x10000 src/../src/test-tini.rel src/dip-tini.rel src/led-tini.rel src/clock-tini.rel src/lcd-tini.rel And here is the output : COMPIL LINK + "aslink" -nf "test-tini" src/.rel: cannot open. It stop after the fisrt dot it meets. ==> Does anyone have a clue ? -- Arnaud Constancin INRIA Rhone-Alpes -- |
From: Jesus Calvino-F. <Je...@ec...> - 2003-07-03 19:30:43
|
Hi Arnaud, Just uploaded to the CVS repository lkmain.c version 1.19 that should fix the problem. If you can build SDCC, can you give it a try and let me know if it works? Jesus At 10:56 AM 7/3/2003 +0200, you wrote: >Hello all ! > >I have a big problem... I make a port of a big projet with a lot of files >having a special naming convention ! >Files are named like this : sourcefile.tini.c <- there is more than one dot ! >or like this : path/../sourcefile.c > >For each file, SDCC made a sourcefile.tini.rel well. >But the link doesn't work :^( >It tells me: > > sourcefile.rel : cannot open. >or > path/.rel : cannot open. > > > >Here is a sample script I use : > >echo COMPIL >sdcc -c -mds390 --model-flat24 --stack-10bit src/../src/test-tini.c # OK !! > >echo LINK >sdcc -mds390 --model-flat24 -V --stack-10bit -Wl-r --xram-loc 0x100080 > --code-loc 0x10000 src/../src/test-tini.rel src/dip-tini.rel > src/led-tini.rel src/clock-tini.rel src/lcd-tini.rel > > > >And here is the output : > >COMPIL >LINK >+ "aslink" -nf "test-tini" >src/.rel: cannot open. > > >It stop after the fisrt dot it meets. > > >==> Does anyone have a clue ? > > > >-- > Arnaud Constancin > INRIA Rhone-Alpes >-- |
From: Arnaud C. <Arn...@in...> - 2003-07-04 09:50:25
|
Le Jeudi 03 Juillet 2003 21:30, Jesus Calvino-Fraga a =E9crit : > Hi Arnaud, > > Just uploaded to the CVS repository lkmain.c version 1.19 that should fix > the problem. If you can build SDCC, can you give it a try and let me know > if it works? The cvs stops on the following file : U sdcc/support/tests/internal/testmacro.c I don't know why ! =2D-=20 Arnaud Constancin INRIA Rhone-Alpes =2D- |
From: Jesus Calvino-F. <Je...@ec...> - 2003-07-04 17:24:06
|
The CVS repository does that some times. Just keep trying. Jesus At 11:48 AM 7/4/2003 +0200, you wrote: >Le Jeudi 03 Juillet 2003 21:30, Jesus Calvino-Fraga a =E9crit : > > Hi Arnaud, > > > > Just uploaded to the CVS repository lkmain.c version 1.19 that should= fix > > the problem. If you can build SDCC, can you give it a try and let me= know > > if it works? > >The cvs stops on the following file : >U sdcc/support/tests/internal/testmacro.c > >I don't know why ! > >-- > Arnaud Constancin > INRIA Rhone-Alpes >-- > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Arnaud C. <Arn...@in...> - 2003-07-07 09:43:33
|
Le Vendredi 04 Juillet 2003 19:15, Jesus Calvino-Fraga a =E9crit : > > > Just uploaded to the CVS repository lkmain.c version 1.19 that should > > > fix the problem. If you can build SDCC, can you give it a try and let > > > me know if it works? > >The cvs stops on the following file : > >U sdcc/support/tests/internal/testmacro.c > >I don't know why ! So... the CVS just does'nt quit, but it download all the necessary files ! = It=20 compile ! The new CVS version of SDCC works ! I don't have path problems... Thank you ! =2D-=20 Arnaud Constancin INRIA Rhone-Alpes =2D- |
From: Jesus Calvino-F. <Je...@ec...> - 2003-07-07 17:19:09
|
Excellent. Thanks! Jesus At 11:41 AM 7/7/2003 +0200, you wrote: >Le Vendredi 04 Juillet 2003 19:15, Jesus Calvino-Fraga a =E9crit : > > > > > Just uploaded to the CVS repository lkmain.c version 1.19 that= should > > > > fix the problem. If you can build SDCC, can you give it a try and= let > > > > me know if it works? > > > >The cvs stops on the following file : > > >U sdcc/support/tests/internal/testmacro.c > > >I don't know why ! > >So... the CVS just does'nt quit, but it download all the necessary files != It >compile ! >The new CVS version of SDCC works ! I don't have path problems... > >Thank you ! > >-- > Arnaud Constancin > INRIA Rhone-Alpes >-- |
From: Simon H. <Sim...@co...> - 2003-07-06 23:36:44
|
karthik bala: > fine guess. I am into some of the undocumented methods tooo. I am > waiting for such postings from this group . At present i am mainly > concentrating on the s/w segment. I would get deep into the h/w > concepts dealing with this too. Andy Green: > It will be a bit of a short experiment -- there is only one undefined=20 > opcode in 8051, 0xa5. There are some other undefined instructions, too. For example, I recall = an Atmel datasheet saying something like 'mov A, ACC' was undefined. Remember, though, that hacks like this are more often about finding = things that the designers didn't think of, not about the things the = designers wouldn't specify. |
From: karthik b. g. <sdc...@ya...> - 2003-07-20 14:40:35
|
Dear friends, I made an interesting observation. The stack pointer moves on each function call and the controller restarts/hangs when the stack limit is reached. This occurs especially when a function calls a function and that function inturn calls another function and the flows goes on. So, I think it is better to avoid calling a function from within a function . Even if we do that, we have restrict it to a limit. MONITOR THE STACK ..... karthik bala guru li...@ya... --- Simon Hosie <Sim...@co...> wrote: > karthik bala: > > fine guess. I am into some of the undocumented > methods tooo. I am > > waiting for such postings from this group . At > present i am mainly > > concentrating on the s/w segment. I would get deep > into the h/w > > concepts dealing with this too. > > Andy Green: > > It will be a bit of a short experiment -- there is > only one undefined > > opcode in 8051, 0xa5. > > There are some other undefined instructions, too. > For example, I recall an Atmel datasheet saying > something like 'mov A, ACC' was undefined. > > Remember, though, that hacks like this are more > often about finding things that the designers didn't > think of, not about the things the designers > wouldn't specify. > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Shehryar S. <she...@ul...> - 2003-07-20 15:31:00
|
Dear Friend I think you never paid attention during your computer architecture course. It's just the way a stack works in every processor. Every call you make to a function the processor pushes the current program counter location on to the stack if the stack is say 2 locations deep then greater than 1 nested function call from within a function will cause a stack over flow and the processor will never be able to return to the point from where it made the call. Function calls from within functions are dependant on stack depth. Depending on processor architecture if the nested call exceeds the stack depth the last location on the stack is either over written or the last pushed address will be lost. In any case stack over flow as well as under flows ( under flow is when you 'pop' more than what has been 'pushed') to be avoided and such information is always given in microcontroller data sheets. Same is with nested interrupts, nested interrupts are also dependant on stack depth. These are considerations that you need to take in account when writing code specially for smaller microcontrollers. Best Regards Shehryar ----- Original Message ----- From: "karthik bala guru" <sdc...@ya...> To: <sdc...@li...> Sent: Sunday, July 20, 2003 3:40 PM Subject: RE: [Sdcc-user] crashing a microcontroller - killing 8051 - hanging a controller !! > Dear friends, > I made an interesting observation. The stack > pointer moves on each function call and the controller > restarts/hangs when the stack limit is reached. > This occurs especially when a function calls > a function and that function inturn calls another > function and the flows goes on. > So, I think it is better to avoid calling > a function from within a function . Even if we > do that, we have restrict it to a limit. > > MONITOR THE STACK ..... > > karthik bala guru > li...@ya... > > > > --- Simon Hosie <Sim...@co...> wrote: > > karthik bala: > > > fine guess. I am into some of the undocumented > > methods tooo. I am > > > waiting for such postings from this group . At > > present i am mainly > > > concentrating on the s/w segment. I would get deep > > into the h/w > > > concepts dealing with this too. > > > > Andy Green: > > > It will be a bit of a short experiment -- there is > > only one undefined > > > opcode in 8051, 0xa5. > > > > There are some other undefined instructions, too. > > For example, I recall an Atmel datasheet saying > > something like 'mov A, ACC' was undefined. > > > > Remember, though, that hacks like this are more > > often about finding things that the designers didn't > > think of, not about the things the designers > > wouldn't specify. > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: karthik b. g. <sdc...@ya...> - 2003-07-22 18:05:03
|
ya i'm basically an Electronics Engg . Thanx for your tips . Xpecting the same from you. regards, karthik bala guru --- Shehryar Shaheen <she...@ul...> wrote: > Dear Friend > I think you never paid attention > during your > computer architecture course. > > It's just the way a stack works in every processor. > > Every call you make to a function the processor > pushes the current program counter location on to > the > stack if the stack is say 2 locations deep then > greater than > 1 nested function call from within a function will > cause > a stack over flow and the processor will never be > able to > return to the point from where it made the call. > > Function calls from within functions are dependant > on > stack depth. Depending on processor architecture if > the > nested call exceeds the stack depth the last > location on the > stack is either over written or the last pushed > address will > be lost. > > In any case stack over flow as well as under flows ( > under flow is when you > 'pop' more than what has been 'pushed') to be > avoided and such information > is > always given in microcontroller data sheets. > > Same is with nested interrupts, nested interrupts > are also dependant on > stack depth. > > These are considerations that you need to take in > account when writing code > specially > for smaller microcontrollers. > > Best Regards > > Shehryar > > > ----- Original Message ----- > From: "karthik bala guru" <sdc...@ya...> > To: <sdc...@li...> > Sent: Sunday, July 20, 2003 3:40 PM > Subject: RE: [Sdcc-user] crashing a microcontroller > - killing 8051 - hanging > a controller !! > > > > Dear friends, > > I made an interesting observation. The stack > > pointer moves on each function call and the > controller > > restarts/hangs when the stack limit is reached. > > This occurs especially when a function calls > > a function and that function inturn calls another > > function and the flows goes on. > > So, I think it is better to avoid calling > > a function from within a function . Even if we > > do that, we have restrict it to a limit. > > > > MONITOR THE STACK ..... > > > > karthik bala guru > > li...@ya... > > > > > > > > --- Simon Hosie <Sim...@co...> > wrote: > > > karthik bala: > > > > fine guess. I am into some of the undocumented > > > methods tooo. I am > > > > waiting for such postings from this group . At > > > present i am mainly > > > > concentrating on the s/w segment. I would get > deep > > > into the h/w > > > > concepts dealing with this too. > > > > > > Andy Green: > > > > It will be a bit of a short experiment -- > there is > > > only one undefined > > > > opcode in 8051, 0xa5. > > > > > > There are some other undefined instructions, > too. > > > For example, I recall an Atmel datasheet saying > > > something like 'mov A, ACC' was undefined. > > > > > > Remember, though, that hacks like this are more > > > often about finding things that the designers > didn't > > > think of, not about the things the designers > > > wouldn't specify. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: karthik b. g. <sdc...@ya...> - 2003-07-04 15:35:46
|
Dear friend, fine guess. I am into some of the undocumented methods tooo. I am waiting for such postings from this group . At present i am mainly concentrating on the s/w segment. I would get deep into the h/w concepts dealing with this too. Xpecting your usual response, karthik bala guru li...@ya... --- Simon Hosie <Sim...@co...> wrote: > karthik bala guru: > > I am into something like finding all the possible > > ways to to bring a perfectly operating controller > to > > halt(standstill) using just the coding . > > > > I want just the ways in which a controller can > > be affected or its operation distorted using > > software(coding) alone. > > Are you trying to get modes of operation outside of > what is given in the datasheet? Like drawing excess > current and desoldering itself, or what? > > Something like how on the 6510 (at least, the one > used in the C64) would crash if you executed the > undocumented opcode 0x02? > > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Andy G. <an...@wa...> - 2003-07-04 15:56:33
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 04 July 2003 16:35, karthik bala guru wrote: > Dear friend, > fine guess. I am into some of the undocumented > methods tooo. I am waiting for such postings from > this group . At present i am mainly concentrating > on the s/w segment. I would get deep into > the h/w concepts dealing with this too. It will be a bit of a short experiment -- there is only one undefined=20 opcode in 8051, 0xa5. =2D -Andy =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/BaOrjKeDCxMJCTIRAldiAKCUA33ZrGMXgHKcZNwkyWyCbHigNQCfc+Jx SDRPPo/bwWqGnn6pOozImLI=3D =3D8+DD =2D----END PGP SIGNATURE----- |