Jump to content
 

Orunmila

Member
  • Content Count

    221
  • Joined

  • Last visited

  • Days Won

    28

Orunmila last won the day on December 17 2020

Orunmila had the most liked content!

Community Reputation

51 Excellent

About Orunmila

  • Rank
    Teacher

Recent Profile Visitors

6,966 profile views
  1. Can you be a bit more specific with that information please? Which Silicon revision are you using? Also we were able to get the workaround to work at some temperatures but it was not working correctly across the voltage and temperature range permitted in the spec. How did you test that it worked?
  2. OpenOCD is not really CPU specific. It supports debugging via GDB. It allows you to set breakpoints and single step the code. This is all the stuff you had to implement already. If you have GDB support via OpenOCD for the programmer you will be able to use it with IDE's such as VSCode, Eclipse etc. to debug the device.
  3. We have been pondering doing something like this for ages. Bonus points if you can debug using Open OCD using that thing !
  4. The way I2C works when you add a second device no changes should be required in your configuration. If the working address stops working it is usually either because of multiple devices with the same address or it is due to an electrical problem. Could be the capacitive loading on the bus or even reflections if you have a star with long lines without termination (could also be incorrect size of or even missing pullup resistors). What I would suggest is to try and reduce the speed after ensuring that you have different addresses. Also look at the lines with an oscilloscope and check to see if the bus is being pulled down (ACK) after the address. If not no device is recognising the address.
  5. I have also catalogued a number of typical I2C errors including typical addressing errors in this blog post
  6. Perhaps I can explain it better with an example. If you wrote code like this, which is using a non-compound literal int i = 7; where do you expect the 7 to be located in the map file? Of course the correct answer is that it gets encoded as part of the assignment code, so it would end up in the TEXT segment with the other code, but there is no rule for this, if this is an auto variable it will just be in the TEXT segment, if it was statically allocated though the compiler may, as an optimization, copy variables in bulk into the ram location of i, but I would say even in that case it goes in TEXT. The problem is not whether or not the literal is valid C or not, of course it is valid, but I think your expectations of where (or perhaps more accurately IF) memory is allocated for the struct are not quite right. I think if you look at the ASM generated for your initializer it will make more sense. In the Microchip PIC's I spent a lot of time on your initializer would compile to something like this MOVLW 2; MOVWF actualCat MOVLW 17; MOVWF actualCat+4 Now if you have code that takes the address of that, it will actually return the address of what? Perhaps the instruction MOVLW? This is dangerous because it will not necessarily behave the way that you expect. If you do a cast like you are doing, depending on the implementation in the compiler it may create a temporary variable on the stack, and then return the address of this temporary variable. This is also dangerous because although your allocation will work the pointer will not be valid later in the application, and even if you test it and the memory is still intact it may be deemed fair game to the compiler to hand out to someone else at the time, in that case it is dangerous as you are pointing to unallocated memory and will get undefined behavior (even in C++). Yes of course I am also using designated initializers in the examples in the article above, I agree that they work great (not only on small devices, on all devices), but of course you lose control of the memory allocation if you do it the way you are doing it (specifically casting the anonymous struct and then taking it's address) because if you start casting things you better know what you are doing because casting == telling the compiler you know better than the compiler - never a great idea 😉 I generally avoid designated initializers though since it was only added in C99 and many compilers from embedded vendors do not yet support them so I always run into portability problems when I do that.
  7. You are initializing the structure using an anonymous structure which is not specified to be located in a specific setion. I have not investigated it any further but I think it might actually be dangerous to take the pointer of an anonymous struct like that because I believe it will be allocated on the stack and it will not be obvious when the memory is being freed (although I may be mistaken here, it still looks dangerous to me). I think what you should do is something like this #define BOB_SECTION __attribute__((section(".bob"))) #define FRANK_SECTION __attribute__((section(".frank"))) struct Cat { uint16_t heads; uint16_t tails; }; FRANK_SECTION struct Cat actualCat = { .heads = 2, .tails = 17 }; BOB_SECTION struct Cat* gNeelix = &actualCat;
  8. I would also suggest you take a look at this because you seem to be writing to the port register bits which will cause read/modify/write errors. Is it possible that the pin is actually toggling really fast?
  9. When that happens it usually indicates something wrong with the connection to the device. The strengths of the pin drivers are not the same on the different programmers. Perhaps you have marginal amounts of capacitance on the lines?
  10. I was not able to create a satisfactory workaround on the A1 or A3 Silicon. We were able to get Rev B2 Silicon which resolves the problem. The official workaround on A1 silicon is not to use the peripheral but instead to bit-bang the I2C. From the Errata:
  11. Thanks for pointing out the mistake, I have updated the post to show 2.0 LSB which is the correct Offset error for this device
  12. Orunmila

    Ms

    If you load that project it should load with the working version.
  13. Orunmila

    Ms

    Here is the project I generated, sorry for the random name 🙂 wdqwd.zip
  14. Orunmila

    Ms

    I tested it and from v1.80.0 of the PIC10/12/16 library onwards this seems to be broken. If you open the "Versions" tab and find the previous version it still works fine. You can switch to the old version in the IDE. It looks like this on my machine. Right-click on the 1.78.1 version and select Mark library for load and then press the load button at the top next to where it says "Versions" it will appear. After doing this I bet it will work just fine. It builds. I will attach the project for you also.
×
×
  • Create New...