Jump to content

wolahr

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About wolahr

  • Rank
    Newbrie
  1. wolahr

    .....than One Execution Thread: Delay_us

    Why not? Especially when there may be a higher priority interrupt which can interrupt the interrupt if something more pressing occurs? I can see that keeping interrupts short is a good idea in general, but is there some special or non-obvious reason why putting a delay in is dangerous? <{POST_SNAPBACK}> Never delay in an interrupt!.....unless you have to. <{POST_SNAPBACK}> So, if I do have to delay in an interrupt, could you arrange the linker to allow delay calls to be called (inlined) from more than one thread, and perhaps create a warning saying:
  2. wolahr

    .....than One Execution Thread: Delay_us

    Why not? Especially when there may be a higher priority interrupt which can interrupt the interrupt if something more pressing occurs? I can see that keeping interrupts short is a good idea in general, but is there some special or non-obvious reason why putting a delay in is dangerous?
  3. wolahr

    Linker Problems On Pic18f4455

    Hi dave, Thanks for fixing this so quickly Regards Will
  4. Bug description: I just compiled, linked and ran some code on a PIC18F4455, and noticed some unexpected behaviour in my program. On investigation I found that some of my data (a char[] array) had been stored in the 0x060-0x0ff range. On the PIC18F4455 this range contains SFRS (note details given below) Steps to reproduce: declare an array of over 80 bytes: char *SomeArray= " Any of this text stored between 0x80 and 0xFF may be corrupted" compile, link, run debugger and see where your data is. Expected behaviour: I expect data not to change unless it is modified by my code... Is the problem 100% reproduceable: Yes. IDE version: MPLab 7.34 Compiler: BoostC Compiler version: 6.30 Target device: PIC18F4455 OS: Comments: 1 - At a guess your linker is only checking the start address for blocks of ram is valid, or only the first n bytes. Ive only seen this problem using long (200 byte) blocks. 2 - In my program both high and low priority interrupts are enabled 3 - At first glance, the data sheet suggests 0x00-0xff are all General Purpose Registers, this is not true 0x80 - 0xff are SFRs in the access window, i.e. these addresses are mapped to SFRs. See device datasheet fig 5-5 on page 66 for more details. 4 - Short term fix for users with similar problems: char *DontUseThisArea[128] @ 0x80; I think this is a fairly serious issue as it could cause some occasional unexplained and almost entriely undebuggable problems in peoples projects.
×