Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by mikew

  1. Hi,

    Some delay in responding to your thoughts, and your mention of a virus scan is not far off the mark, but in the wrong direction!

    To cut a long story short, it turned out that it was my all-singing-all-dancing virus checker that was the culprit.  The penny dropped when I attempted to re-install my version 6.97 toolchain; this was stopped because it declared it contained a trojan!!  Ultimately, after a lot of faffing about, it simply required certain compiler files etc. to be excluded from any scanning.  The culprit is F-Secure Safe, which I have been using for years; they obviously snook in an update which then caused me to waste 2 days going round in circles.  Grrrrrrrrr!

    Again, thanks for taking the time and trouble to respond. (I never got anything from Sourceboost support)



  2. Hi,

    Thanks for the response.  The Boost C I have been using for years is Version 6.97 - I have never had the need to upgrade to Version 7.xx. So I can't think that this has anything to do with this sudden "relapse"!! 

    Since I posted this, I've discovered that the compiler now actually does nothing!!  Clicking on 'OK' in the message, it continues without any warnings, declares 'Success'   and 'Done'   but has not parsed the source file and has not produced a new .hex file.

    I'm thinking that a fresh install might cure the problem, but not sure if this is a bad idea without having some idea why it has suddenly happened for no apparent reason.


  3. I have been using Sourceboost C Version 6.97 for some time, without any problems.  Today I re-compiled a file and obtained the following odd message:-
    Compiler executable was renamed  from boostc.pic18.exe to boostc_pic18.exe
    If you see this dialog this means that you still try to use the old compiler name.
    Nothing has been changed in the installation in any way, and I am at a loss to understand what this error means.  After choosing ‘OK’ the compile/link etc. process seemed to continue correctly.
    I am at a loss as to why this "error" message has suddenly appeared for no obvious reason.  In this case I can't blame Windows 10 updates!!
    Perhaps someone more knowledgable of Boost C can shed some light?

  4. Hi,

    Thanks for the response. The webinar is interesting, but doesn't really give any clues as to my problem. I apologise for getting the PIC wrong - it should, of course, be 12F683.

    I've checked all the usual suspects, CONFIG, ANSEL, ADCON0 etc, but nothing changes the effect. I haven't looked to see if the effect is present on any other GPIO's; for my intended application these were the only two of interest.


    In the meantime I've solved the 'problem' by changing to a 12F615 - very similar but I wanted to use the EEPROM in the '683.

  5. Hi,

    I'm hoping someone with more knowledge and experience may be able to solve a riddle? I have discovered (the hard way!) a peculiar behaviour of this pic. Simply put, GPIO4 controls the operation of GPIO1. For example, if both are set high, when GPIO4 is then set low GPIO1 follows about 500ns ( 1 instruction time at 8MHz? ) later. I've looked at the code, SourceBoost C and the listing file and they are correct. I've scoured the Microchip documents and trawled the internet, but found nothing that I might have missed. At first I firmly believed it was the two chips I had that were just faulty, but two more from a different source behave exactly the same.


    Any ideas, anyone?



  6. Many thanks for your assistance, which has allowed me to solve the problem. However, having now successfully created the hex file I have encountered another problem!

    I have a TL866CS programmer that I have used without any problems for a variety of different PIC's. But with the 18F2520 a few bytes fail to program properly; programming followed by automatic verification succeeds for the code, but fails for the CONFIG section, and then performing another code verification fails. The failed bytes are always on a "page" boundary, i.e. 0x100, 0x200, 0x300 etc. I am trying to work out if this is a code problem, ( very unlikely, I think ) or a programmer problem, (most likely?) or a PIC problem ( possible, until I get more devices for comparison.)

    Any light the experts can shed on this could save me a lot of wasted time, especially if anyone has experience of this programmer, which seems to be well made and a popular gadget.

  7. I have successfully used the floating point library for PIC16F devices and wished to try an 18F2520 device. However, I discover that the compiler ( I have Version 6.97) flags an error that " incompatible .obj or .lib" found. The only information in the Float PDF is that the float.pic18.lib covers the 18F devices, but nowhere can I find a list of specific types that are covered.


    I wonder if anyone with more experience can provide any advice and information in order that I may now choose a PIC18F device that is supported by the floating point library.



  8. I have encountered a problem using the assembler within BoostC. I am trying to translate a Microchip assembler program to C, but wish to leave some parts as assembler, using the asm{} feature. This works fine, apart from one instruction, which BoostC flags as "unknown identifier" The identifier is a label in the assembly code, referencing a code memory address; this is then used with the movlw instruction within the same section, thus:





    movlw TRFReset


    and it is this last instruction that gives the error. I'm assuming the syntax is correct, and it is the BoostC assembler that is problematic? Although I'm not convinced that as given it is correct. 'W' is an 8-bit register and the full address referenced by the label is 13 bits, so am I missing something here? Incidentally, the address is used to modify the program counter for entry into a jump table.

    Any suggestions would be most welcome. :(



  9. I may be hi-jacking this thread, apologies if so.

    My attempts to create a working program in Boost C for the 16F886 have met with dismal failure. I'm hoping that someone more versed in the use of this PIC may be able to help. I'm quite familiar with the 16F876, but my problem seems to be in configuring the '886 clock source, as well as the other features that are not present on the '876.


    I wish to use the internal clock running at 1MHz and have used what seem to be correct values in OSCCON, CONFIG1 and CONFIG2, but the result is a seemingly 'dead' PIC. Incidentally, I know it's not faulty as a hex file I found on another project page for the '886 works fine. I even tried using the values in this code, but no different result.


    I have this nagging suspicion that there is something about this PIC that I'm missing, but despite studying the data sheet from start to finish it has eluded me!


    Any suggestions welcome...



  10. Hi,

    This is really a question for future reference. I have often used the 16F876 for projects, but it's now obsolete. I have a friend who has used a PICAXE, and that has a 16F886. So, I thought, that's probably one to try. However, I discover that neither of my programmers support this PIC, and my minimal research suggests that it's programming algorithm is somehow different from the rest.

    So, my question is, what is peculiar about this PIC? How is the programming different? And how might I modify a programmer to support it? BTW, I've been on to the makers of one of my programmers that I think would only require a firmware update, only to be informed that "no updates are planned in the foreseeable future", but no other information forthcoming.


    Any suggestions?



  11. Hi,

    Not directly related according to your description, but I had a similar problem with a PIC project. It had a 16F877a in a TQFP fairly close (~5cms) to a couple of relays switching 230VAC. Mostly it worked fine, but occasionally it was clear the code had gone berserk!

    I eventually discovered that an earthed aluminium screening can cured the problem, presumable by protecting the PIC from EMI produced by arcing at the relay contacts.

    You may consider doing the same, as you may have HF EMI emanating from any inductors or transformers?

  12. Hi,

    I've recently been attempting to use a 16F876A for I2C comms with an external EEPROM. I have used the examples posted in the links from this site by R S A Bear, for which I am much obliged. I've reduced the code to cut out the comms with the second PIC, leaving the EEPROM read and write routines. This example also uses the i2c_driver.h file in the boostc distribution.


    However, I can't get my code to work properly, and I wonder if anyone else has used these examples, or has some ideas to point me in the right direction? I find that the eeprom write function is almost correct; by looking at the eeprom contents in a separate eeprom programmer the first two bytes written are always incorrect - the rest is fine. Which is a puzzle! I wondered if the SCL speed was too high at 100kHZ and tried reducing it to 50kHz, but this makes no difference.


    The eeprom read function doesn't work at all, that is, totally corrupted data is returned. However, the returned data is always the same, which again is a puzzle. I am outputting the data to an LCD, but also viewing the SDA and SCL on a DSO and the waveforms look OK. At this stage I'm loathe to drag out the logic-state analyser, and I'm not convinced it would shed any light on my problem.


    As this is my first encounter with I2C I get this funny feeling that I'm missing something really simple!




  13. Thanks for the replies all of you, despite not having ESP!! After spending (wasting?) a further 20 mins scrutinising the code I decided the best way was to back-track and start over. Hey presto - problem solved, or at least eliminated. However, I'm still not sure what the error message means; perhaps the file had become corrupted in some way and hence was spurious?



    Mike W

  14. Please can anyone help with this problem?

    I have a program which I have been modifying and which has now produced an error message:


    Parameter buffer overflow


    about 20 times, even for comment lines. ending with:


    Fatal unexpected end of file


    Obviously I have made a silly mistake, but since the first set of error messages are meaningless to me I don't really know where to start looking! I have looked carefully at every line and cannot see any semantic errors.

    Hopefully someone can point me in the right direction rather than post the whole source code here, although it's not very big.



  15. Thanks for your speedy response!

    That's what is puzzling me; my program does use interrupts, but only from Timer1 to generate a time-of-day output. The sudden appearance of 'threads' seems inappropriate and unnecessary. My program is very straightforward, and I would have no idea how to incorporate threads into an embedded PIC program - I'm not using any OS.


    It seems to me that there is some sort of conflict between the FP routines (for example) and the I2C functions, since the I2C was the last thing I added to the program.


    I suspect that the message is spurious, in the sense that it emanates from (for me) unwanted functionality in the i2c_driver.h that I have taken from the BoostC distribution without a full inspection of its content. It works on its own in a separate program, where, incidentally I sussed out what was missing to make it work before. I now have some 24FC1025 eeproms that expect a 16bit address in two bytes.


    I'll now go and wade through the .lst file and find out what __rem_8_8 is doing!!



    Mike W

  16. I have recently encountered the following message from Boostlink 6.92:



    Building CASM file

    Serious Warning: Possible sw stack corruption, function '__rem_8_8' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)


    Memory Usage Report


    RAM available:368 bytes, used:258 bytes (70.2%), free:110 bytes (29.8%),

    Heap size:110 bytes, Heap max single alloc:95 bytes

    ROM available:8192 words, used:7259 words (88.7%), free:933 words (11.3%)



    (I have edited out most of the other messages, which I can understand!)


    Perhaps someone who is more conversant with BoostC (and a better programmer) can shed some light on what the serious warning means?


    The function __rem_8_8 presumably comes from either the I2C header or the floating point library, both of which my program uses. My particular problem is not understanding the term 'asynchronous thread' in the context of BoostC.


    Please, help!!


    Mike W

  17. Thanks for your assistance, Reynard. One assumption I have made is that all EEPROM's are the same, but different! The ones I have been using don't seem to have a page mode function, but a write protect on pin 7. I'd guess that the example code is intended for the multibyte mode; I didn't include all the code as it's already in the examples on the Sourceboost site.

    I've found another example that is much simpler, and obviously uses single byte read/writes with the I2C routines included, and which I can understand!!


    I'll pursue this for the moment and come back to the other one when I feel I have the time.


    Again many thanks for your help.


    Mike W

  18. Thanks Reynard. To be honest, I don't know!! I've simply taken the example code and tried to use it to understand how I2C works. For information, the read and write routines are as below:-




    // I2C Device constants



    // define External I2C slave (Hardware) addresses

    #define xee_slave 0xA0 // Base address of the EEPROM



    // Read from the External EEPROM


    // s is a pointer to the destination buffer to data read from the EEPROM

    // HW_address is the hardware address of the i2c device

    // ic2_addr is the target internal address within the External EEPROM

    // count is the number of bytes to be read starting at i2c_addr


    void read_XEE(char *s, char HW_address, unsigned short i2c_addr, unsigned short count)


    short i;



    i2c_write(HW_address); // send XEE i2c address

    i2c_write(i2c_addr >> 8); // send XEE internal HIGH address

    i2c_write((char) i2c_addr & 0x00ff); // send XEE internal LOW address

    i2c_restart(); // send i2c_restart


    // sending XEE read command via i2c_write

    i2c_write(HW_address | 0x01); // send device address + RD to I2C device


    // XEE read loop

    for (i=0;i<count-1;i++)

    *s++ = i2c_read(0);

    *s++ = i2c_read(1);

    *s = 0;





    // Write to the External EEPROM


    // s is a pointer to the string to be written to the EEPROM

    // HW_address is the hardware address of the i2c device

    // ic2_addr is the target internal address within the External EEPROM

    // count is the number of bytes to be written starting at i2c_addr


    void write_XEE(char *s, char HW_address, unsigned short i2c_addr, unsigned short count)


    short i;



    i2c_write(HW_address); // send XEE i2c address

    i2c_write(i2c_addr >> 8); // send XEE internal HIGH address

    i2c_write((char) i2c_addr & 0x00ff); // send XEE internal LOW address


    // XEE write loop

    for (i=0;i<count;i++)






    I have observed that increasing the value of 'count' beyond 16 causes the data to overwrite from address 0000, as the EEPROM data sheet says, but what it doesn't say to me is how the 'pointer' is increased beyond the 16byte boundary; the HIGH address and LOW address in the example seem to be inscrutable!


    So, please, what is the significance of multibyte or page mode?



    Mike W

  19. Mike,


    Are you working in multibyte write or page write mode ?


    Memory is in 8 byte pages. For multibyte you can write 4 bytes at a time which can cross a page boundary. You tell it the start address and write 4 consecutive bytes from there. If you cross a page boundary remember the write time doubles to 20ms as you have to write over 2 pages.


    For page write you write 8 consecutive byte in a complete page. When you set the start address the lower 3 bits will be ignored and start internally = 000. If you write less than 8 bytes I assume it doesn't matter it keep the previous data. Don't hold me to that bit.





  20. As part of my voyage of discovery I decided it would be nice to add I2C to my latest project! I've started out by experimenting with the example code from the forum - which all works as I guess it should. But I'm hoping someone far more conversant with I2C can help me with what should be a simple problem - but I just don't get it, and the EEPROM data sheets don't shed any light.


    I wish to read/write to a 24C04 EEPROM using a 16F876 as master; the I2C routines in the example program read/write to the bottom 16 bytes OK, but so far I've not discovered how to access the rest of the EEPROM.


    I'm obviously missing something that must be staring me in the face... please help!!



    Mike W

  21. Can any expert on PICs shed some light on this problem? I'm using a 16F877A as a central heating controller, with both Timer0 and Timer1 generating interrupts. The processor clock is 20MHz, and the desired combination of accuracy and divider ratio constraints leads to T0 interrupting 90 times a second and T1 20 times a second. The program will run fine for days, then 'randomly' fail. T1 is used to generate time of day, ie hours:minutes:seconds and the failure is apparent when the 'clock' stops. I have not investigated what limitations the PIC or BoostC places on interrupt stack depth, nor if there are any other interactions within the PIC between timer interrupts. I'm puzzled by the apparent randomness of the event; I'm also at a bit of a loss on how to debug the problem. The PIC is an SMD on a module along with an FTDI USB chip, but does have ICSP.


    Any suggestions gratefully received.

  22. put your long into a union along with an array of 4 unsigned chars.


    union {
     unsigned long temp;
     unsigned char arTemp[4];
    } longTime;
    eeprom_write(store_day, longTime.arTemp[2]);
    eeprom_write(store_day+1, longTime.arTemp[1]);
    eeprom_write(store_day,+2 longTime.arTemp[0]);


    or something similar to this.






    Thanks for the quick response, although I feel rather silly! Of course a union is exactly what is needed, but not being a programmer I've never actually used one before.

    Best regards.

  23. I wish to store data in EEPROM of a 16F877A. The data is held as a 32 bit value which I periodically (every 24 hours) wish to copy into EEPROM. I've used the following snippet, but it only saves the least two significant bytes. At the risk of confusing, the code is actually only to save 3 bytes, as the most significant byte I realised would always be zero, to save EEPROM space.

    Perhaps someone can suggest a better way of achieving this data transfer.


    if (store_flag)
    eeprom_write(store_day, day);
    store_val=(unsigned char)long_temp;
    eeprom_write(store_day, store_val);	   //save hi-byte
    store_val=(unsigned char)long_temp;
    eeprom_write(store_day, store_val);	//save mid-byte
    store_val=(unsigned char)long_temp;
    eeprom_write(store_day, store_val);	//save lo-byte

  24. Thanks for the quick response. Of course you are correct, I have mis-read the data sheet; I was clutching at straws....

    ...however, whilst on the site I took the opportunity to download Vers. 6.87. The following is the 'same' fragment from the listing file produced by this version from the same C source. The important difference to me is that this now works as expected and I am reluctant to spend any more time looking for problems!

    As you can see, there are differences in the object code, and not just to the labels; perhaps you can explain why the previous object always returned the ADC value for channel 0, irrespective of the channel passed to the subroutine.





    0578 30C7 MOVLW 0xC7

    0579 059F ANDWF gbl_adcon0, F

    057A 3007 MOVLW 0x07

    057B 056B ANDWF ADC_Read_00000_arg_channel, W

    057C 00FC MOVWF CompTempVar564

    057D 0DFC RLF CompTempVar564, F

    057E 0DFC RLF CompTempVar564, F

    057F 0D7C RLF CompTempVar564, W

    0580 39F8 ANDLW 0xF8

    0581 00EB MOVWF ADC_Read_00000_arg_channel

    0582 086B MOVF ADC_Read_00000_arg_channel, W

    0583 049F IORWF gbl_adcon0, F

    0584 141F BSF gbl_adcon0,0

    0585 3002 MOVLW 0x02

    0586 00FC MOVWF delay_ms_00000_arg_del

    0587 2015 CALL delay_ms_00000

    0588 151F BSF gbl_adcon0,2

    0589 label101

    0589 191F BTFSC gbl_adcon0,2

    058A 2D89 GOTO label101

  • Create New...