Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
cpcdos(R)

Homepage E-mail

FRANCE [Jura],
17.02.2015, 13:22
 

CLI and STI (asm) in my ISR ? (Announce)

Hi,
I have a problem in my ISR runtime ( Compile with GCC x86 for dos )


In the ISR (18.2Hz), I call a subroutine (with 'call' function).
I test this, but after 3-4 seconds, my program crash! I suspect that when I call a function who was not time to finish their operations, a new ISR instance is launched, etc ..etc .. and my stack increases in my memory and CRASH!

if I use in my program CLI at the begin and STI a the end, or conversely of a ISR function, you think that is a solution ?

Best regards

---
FAVIER Sébastien
http://cpcdos.fr.nf/

ps: Excuse my for my English level, I'm a French student

bretjohn(R)

Homepage E-mail

Rio Rancho, NM,
17.02.2015, 16:38

@ cpcdos
 

CLI and STI (asm) in my ISR ?

The short answer is: No, CLI/STI won't fix your problem.

It is quite possible that your subroutine takes too long, you are overflowing the stack, or any one (or some combination) of several other issues you could be having. You'll need to do some more in-depth troubleshooting to fully understand and isolate what's going on.

For example, if you think the problem is a stack overflow (and that's pretty likely based on your symptoms), you can test for that specific issue. It should be pretty easy to monitor/display the value of the stack pointer (SP) and see if it's what you think it should be. If your program provides its own stack space, it makes things even easier since the value of SP should be pretty consistent. If your program doesn't provide its own stack space, you can still monitor things but it's a little trickier to see if the problem is really related to the stack. Simply knowing that the problem is a stack overflow doesn't solve the problem, of course, but helps you figure out where to start looking. CLI/STI won't fix a stack overflow problem.

And, just so you know, it's NEVER a good idea to call a subroutine from an IRQ handler (like INT 08) that takes a long time to process. If a lot of processing needs to take place, you usually need to gather the appropriate data during the IRQ handler and put it in some kind of buffer, and then process the data in the buffer from outside the IRQ handler when timing isn't as critical.

RayeR(R)

Homepage

CZ,
17.02.2015, 18:09

@ cpcdos
 

CLI and STI (asm) in my ISR ?

Do you use DJGPP for your code? I remeber the caution about a need to lock memory that belongs to ISR (and all routines it may call and all data it may manipulate) to prevent being swapped out from RAM (in case you use swapping-enabled DPMI server like cwsdpmi)
see functions:
int _go32_dpmi_lock_code( void *_lockaddr, unsigned long _locksize);
int _go32_dpmi_lock_data( void *_lockaddr, unsigned long _locksize);
But it would be probably something else...

---
DOS gives me freedom to unlimited HW access.

cpcdos(R)

Homepage E-mail

FRANCE [Jura],
20.02.2015, 07:57

@ RayeR
 

CLI and STI (asm) in my ISR ?

> Do you use DJGPP for your code? I remeber the caution about a need to lock
> memory that belongs to ISR (and all routines it may call and all data it
> may manipulate) to prevent being swapped out from RAM (in case you use
> swapping-enabled DPMI server like cwsdpmi)
> see functions:
> int _go32_dpmi_lock_code( void *_lockaddr, unsigned long _locksize);
> int _go32_dpmi_lock_data( void *_lockaddr, unsigned long _locksize);
> But it would be probably something else...


@bretjohn Thank you for your explications, I understand better how this work.
I have delete all subroutines on this ISR, and put other operations instead of, and this work :-) Thank!



@RayeR, I will keep you informed for this function
Best regards.

FAVIER Sébastien

---
FAVIER Sébastien
http://cpcdos.fr.nf/

ps: Excuse my for my English level, I'm a French student

cpcdos(R)

Homepage E-mail

FRANCE [Jura],
23.02.2015, 15:59

@ RayeR
 

CLI and STI (asm) in my ISR ?

> Do you use DJGPP for your code? I remeber the caution about a need to lock
> memory that belongs to ISR (and all routines it may call and all data it
> may manipulate) to prevent being swapped out from RAM (in case you use
> swapping-enabled DPMI server like cwsdpmi)
> see functions:
> int _go32_dpmi_lock_code( void *_lockaddr, unsigned long _locksize);
> int _go32_dpmi_lock_data( void *_lockaddr, unsigned long _locksize);
> But it would be probably something else...


@RayeR : Thank you this work perfectly :-)


Best regards

---
FAVIER Sébastien
http://cpcdos.fr.nf/

ps: Excuse my for my English level, I'm a French student

RayeR(R)

Homepage

CZ,
23.02.2015, 19:37

@ cpcdos
 

CLI and STI (asm) in my ISR ?

> @RayeR : Thank you this work perfectly :-)

Did it really it was due to unlocked code/data and nothing else you changed? I hoped that swapping out in today size of RAM is nearly impossible. I wrote some code where locking was not implemented and it worked fine on my system with cwsdpmi 7. Later I read some article that it can crash so I add lock/unlock functions...

---
DOS gives me freedom to unlimited HW access.

Back to index page
Thread view  Board view
15192 Postings in 1365 Threads, 250 registered users, 15 users online (0 registered, 15 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum