Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 02:28 05 Feb 2023 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Hoping for some MPASM Assembler help.

     Page 2 of 2    
Author Message
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 08:01am 03 Feb 2023
Copy link to clipboard 
Print this post

OK, so good news... your ISR code works perfectly for traversing up and down your table.  FSR0 is the correct result every time the interrupt is fired.  So, this is not your problem.

I was not able to get the simulator to work to trigger the ISR though.  I had to manually go into ISR.  The PWM5 output IS working correctly, and the PWM5INTF flag is being set but the PWM5IF flag in PIR6 is not being set.  I am not sure if this is a simulator thing or not.

I have NO experience with this part and its DAC.  It looks like your DAC setup is correct though.  I am a bit surprised that you have to use the DACLD to force the sample into the buffer, but hey, Microchip has changed this a few times over the years.  The first thing I thought was that you didn't notice that the output from the DAC is extremely low current which requires a unity gain buffer.  I typically use a MCP601 for that, and then I saw in your setup that you are pointing the DAC outputs internally to the built-in OPAMPs.  That's pretty nifty if these will handle sufficient current for your application.

So... what is wrong?  I am 100% convinced that your table is working, but I am not sure about the interrupt setup.  The PWM itself is definitely working as I can see it toggling the output in the simulator.  I would recommend toggling a spare pin from within the interrupt (like at the start of your ISR) and looking at that pin to see if it really toggles.  This will tell you with 100% certainty that the interrupt is working all of the time, and just not the very first time it is enabled (which I have seen before when something is not setup quite right).  Microchip has had a bad habit of requiring an EXACT order of operations for certain peripherals to work.  Typically you have to bit-set everything, with the enable done last.

I also don't know if the setup for the DACs and OPAMPs is correct.  I would recommend that you enable the DAC1OUT1 and DAC2OUT1 outputs to the pins, which will appear on RA2 and RA5, respectively.  You didn't provide a pin usage map, but I think these are free.  You can put a scope on these while it is running to see if the outputs change here vs. where the OPAMPs outputs are assigned (RA1 and RB1).  To do that just enable  the pin outputs:

bsf DAC1CON0,OE1
bsf DAC2CON0,OE1


This could simply be a setup issue (order of operations) for the DAC or OPAMP setup.  I don't think the interrupt setup is wrong... it's what I would do, but you need to actually do something within the interrupt (toggle a pin) to verify it is working... just having the PWM5 output sent to a pin via PPS is only going to show you that the PWM is working (and it is for sure).

That's my 2 cents.  I am going to see if I can find a design reference for this family that shows setting up the DAC and OPAMP.


Jim
 
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 08:11am 03 Feb 2023
Copy link to clipboard 
Print this post

Attached is the project.  I moved your ISR code into the main program (at 0x0004) because ever since MPLAB-X was released the debugger won't move between individual include files as you walk through code (in the simulator or a hardware level debugger).  The PC always changes and you can watch the code run as instructions in the PROGRAM MEMORY window, but any code location outside of the main code page (0x0000 - where the code starts) won't show any of the labels/changes unless you make a full cross-reference for every sub-routine on every include you use.  I prefer the old method that MPLAB8 does where it just follows the PC across multiple different includes, opening them if necessary.  So, your ISR is in the main page and can be walked through easily.

Also, don't forget to change the TRISx for any pins you setup as outputs for toggling.  In fact, you might want to check to see what the TRIS needs to be set to for the output of the DACs & OPAMPs too.  I know some peripherals that output should be TRIS'd to inputs, but I am not sure what is required for the DAC and OPAMP outputs.

DAC_Code.zip
Edited 2023-02-03 19:25 by JimDrew
 
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 10:51am 03 Feb 2023
Copy link to clipboard 
Print this post

So, after a few hours of looking around I found that every example from Microchip, and even the MCC code creator always enables the DAC as the very first thing it does, followed by setting up any registers.

You have this:

movlb   bank_1 ; ( Bank 1.)
movlw b'10001000' ; Enable FVR_2 Buffer 2 o/p for DAC's, Gain x2.
movwf FVRCON
movlb   bank_11 ; ( Bank 11.)
movlw b'01001000' ; DAC 1 is Disabled, LEFT justified, no external O/p's
movwf DAC1CON0 ; +ve source is FVR_2, -ve source is AVss. ( Vss.)
movlw b'01001000' ; DAC 2 is Disabled, LEFT justified, no external O/p's
movwf DAC2CON0 ; +ve source is FVR_2, -ve source is AVss. ( Vss.)


..and then later in the setup code you have this:

movlb   bank_11 ; ( Bank 11.)
movwf DAC1REFH ; and put into DAC 1. ( LEFT justified.)
clrf DAC1REFL ; ( DAC1REFL<7:6> 2 bits not used.)
movwf DAC2REFH ; Also put into  DAC 2. ( LEFT justified.)
clrf DAC2REFL ; ( DAC2REFL<7:6> 2 bits not used.)
bsf DACLD,DAC1LD ; Output the sample,
bsf DAC1CON0,DAC1EN ; and enable DAC 1 output.
bsf DACLD,DAC2LD ; Output the sample,
bsf DAC2CON0,DAC2EN ; and enable DAC 2 output.


Based on the examples I have seen (and past experience with certain peripherals that need to be "ON" before they will accept any changes), you might try enabling the DAC first, ie:

movlw b'11001000' ; DAC 1 is Enabled, LEFT justified, no external O/p's
movwf DAC1CON0 ; +ve source is FVR_2, -ve source is AVss. ( Vss.)
movlw b'11001000' ; DAC 2 is Enabled, LEFT justified, no external O/p's
movwf DAC2CON0 ; +ve source is FVR_2, -ve source is AVss. ( Vss.)


... then get rid of the two lines that were enabling the DACs.

One other small reminder that I see everywhere - you can't use the DAC *while* the programmer (or debugger) is plugged in or you won't get anything out of it!
 
Bowden_P
Senior Member

Joined: 20/03/2019
Location: United Kingdom
Posts: 119
Posted: 07:04pm 03 Feb 2023
Copy link to clipboard 
Print this post

Hi Jim,
Many thanks for all the time you have put in on this enigma !

I can confirm a few of your points mentioned above :-

I have toggled an o/p pin in the ISR to check that it is being called - was working as expected. ( The "flags,isr_toggle_f" currently commented in the Equates file was used for control.)

The DACs are succesfully buffered by the on-chip op.amps. OPA1 and OPA2, outputting on RA1 and RB1. They commandeer their pins when enabled, and are a really useful feature !
The DAC's are double-buffered due to needing 2 bytes to program, so setting DACxLD controls a simultaneous transfer, and is then cleared by the hardware.

Microchip datasheets are frequently wooly about the order of setting up a peripheral. Often all you get is an explanation of the registers, so my adopted approach is to set all registers as required, then hit the Enable bit ! (On some they do say to disable the peripheral before making changes, perhaps due to trying to avoid a spurious interrupt or output.)

In the DAC_Code_ISR.inc file are 2 other options for the ISR (commented). One uses the complementary "MOVIW,--/++FSR0" instruction - didn't work either. The other works with program memory data recovery for the DAC's - which worked immediately.

I found earlier that if the MOVIW was aided by manually incrementing /decrementing FSR0 prior, then the expected waveform was output - almostly correctly. Not much point doing that with MOVIW !! This is how I have come to conclude that the chip execution of MOVIW is faulted.

I have tried usig the simulator in my MPLABX v3.65, and can confirm I also get no interrupt activity, just endless Main Loop looping - so apparently no surprise there now. I'll look at your .zip code and see if there is any change here.

Thanks again for all your work,
With best regards, Paul.
Nothing so constant as change.
 
Bowden_P
Senior Member

Joined: 20/03/2019
Location: United Kingdom
Posts: 119
Posted: 08:40pm 03 Feb 2023
Copy link to clipboard 
Print this post

Hi Jim,
Just to confirm I get no interrupt activity in my v3.65 simulator with the ISR code in the main .asm at org &x0004.

With best regards, Paul.

p.s. Earlier I added an active 2-pole Butterworth filter to the DAC 2 output using the last on-chip op. amp - OPA3 - and out popped a rather good sine wave. Very pleasing !
Edited 2023-02-04 06:48 by Bowden_P
Nothing so constant as change.
 
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 08:52pm 03 Feb 2023
Copy link to clipboard 
Print this post

Yeah, this must be an issue with the simulator then.  I noticed that there are several "yellow blocks" for the supported features, so this could be one of those.

Your ISR code for generating the value to put into the DACs is working 100%, so that is absolutely not the issue.  You can just move the PC to "isr_pwm5_start" in your ISR and walk through the code until the RETFIE, then move the PC back again and repeat over and over.  You will see that the value being fetched from table is always correct, moving up and down the table just as you intended.  So, if the interrupt is really firing then I think this has to be an issue of the data being put into the DACs is not being updated - likely from not enabling the DAC first before doing any setup of the registers.  You set several things after the fact that directly affect the operation of the DAC.  When the MCC code creator enables something first before changing the associated registers then that would be a good clue.  The OPAMP initialization with MMC code creator enables the OPAMP module very last thing.

So, if you put a pin toggle in the ISR and it is for sure firing every PWM5 timeout then the issue has to be with the DAC storage, since you seem to be able to get something out of the OPAMP output pin assignment.  As I stated before, I have seen some peripherals that "sort of" work when not setup correctly.  I don't recall what it was, but I ran into this same type of problem where a peripheral had to be enabled first, then associated registers setup or it would not function correctly, much like what you are experiencing now.

Also, make sure that your programmer is unplugged from the ICSP if you are using that for programming.  The ICSP (dat or clk) is connected to the DAC apparerntly, and you get nothing or random data from the DACs when the programmer is connected.
Edited 2023-02-04 07:48 by JimDrew
 
Bowden_P
Senior Member

Joined: 20/03/2019
Location: United Kingdom
Posts: 119
Posted: 11:19pm 03 Feb 2023
Copy link to clipboard 
Print this post

Hi Jim,
Thanks for all your confirmations about my code - very reassuring !

As to programming - I put the device into a homemade jig with a ZIF socket complete with its own power supply, and have a PICKit 3 connected to do that. The device is then transferred to a breadboard to run the code. MCLR, ICSPCLK and ICSPDAT are not connected there, but MCLR is pulled up.

I think that as both DAC's output the expected data reliably using the Program memory technique, the setup sequence is OK. I have used EEPROM in the past on such chips as PIC16F877A, where the use requires a very specific sequence to get success, but if there was a rigid sequence to follow for the DAC's then Microchip should really have nailed it down in the datasheet !

Hey-ho, wishful thinking I guess. I have found their datasheets have some omissions or contradictions, and you end up reading between the lines sometimes. This device is no exception. I guess it will happen somewhere in the 578 pages it runs to. Blindly copy-and-paste-ing is often the criminal here !

With best regards, Paul.
Edited 2023-02-04 09:24 by Bowden_P
Nothing so constant as change.
 
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 05:32am 04 Feb 2023
Copy link to clipboard 
Print this post

Typically the examples in the datasheets work.  It's pretty rare there are mistakes, but I have reported a few myself.  The silicon guys hated me for a few years because I was always finding silicon bugs because I write only in assembly code.  You will find many erratas for the PIC24F parts where delays are required after writing to a register before reading the result - I found many of those cases (which never occur when writing in C due to the inherit delays).

If the "program memory technique" seems to work then I would guess this would have to be some sort of timing issue of writing to the DAC registers.  Your ISR code works, and the values being poked into the DAC are from the table so there are no issues associated with that, and walking through the code easily proves that.  I will go look at your program memory technique version.  Maybe its something as simple as needing a NOP after writing to the DACs before forcing the load with DACLD?  I have seen stranger things.

The datasheet itself does not state anything about the setting up the DAC registers, but every example I have seen enables the DAC first and then sets up the attributes for the DAC.  The fact that the Microchip code creator also does this leads me to believe that this is not optional.  That is something you should always follow whne in doubt of the order of instructions to follow.  I would recommend that you try enabling the DAC first instead of disabling during setup and enabling it at the end.  MCC only works with v5.45 and later of MPLAB-X, but you can look at some example code for the PIC16F1709 which has a similar DAC setup.

https://microchipdeveloper.com/mcu1101:project-11

I ordered a PIC16F1776 today for testing myself because it would be good for me to know if there are any quirks with this for any future use of this (or similar family) part.  So, I will know exactly what this issue is as soon as that arrives.  I am actually interested in the OPAMP output as I have a project that could be simplified by eliminating the external dual OPAMP.

I am still puzzles about why the simulator does not trigger the interrupt.  If you manually set the PWM5IF bit the interrupt immediately triggers.  This indicates that the basic interrupts are setup correctly.  For some reason when the PWM5 timer matches the interrupt bit is not occurring.
Edited 2023-02-04 15:46 by JimDrew
 
JimDrew
Newbie

Joined: 07/10/2020
Location: United States
Posts: 35
Posted: 06:10am 04 Feb 2023
Copy link to clipboard 
Print this post

I looked at your "program memory technique" vs the "moviw" version.  There is one difference between the two that could be the reason for what you are seeing.

You noted this:

; Clearing the individual "PWM5INTF,PRIF" interrupt flag also clears the Group "PIR6,PWM5IF" flag apparently,
; so no need to clear that too.

So, your "program memory technique" version is missing the line of code that clears the main interrupt flag for PWM5IF, but this line *is* in the "moviw" version:

bcf PIR6,PWM5IF ; and the PWM5 group PIR6 flag. (Probably redundant.)

I guess you could omit this line from the "moviw" version and see if it magically works.  Ironically, the PWM5IF is what is NOT triggering under the simulator.

Where exactly did you put the code to toggle a pin when an interrupt fires?  I see toggling RC2 to show the main loop is working, but there is no type of DEBUG data to toggle a pin from within the ISR itself.  The TRIS registers are also not set to outputs for anything except for RC2 (main loop toggle) and RC3 (PPS re-direction for PWM5 output).
Edited 2023-02-04 16:24 by JimDrew
 
     Page 2 of 2    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2023