CCS/BOOSTXL-DRV8304H: Cannot get BOOSTXL-DRV8304 and MSP430F5529 EVM combo to work with example TI software

Ed,

Thanks for posting on the MD forum!

I'll comment on the questions I'm familiar with but I will let my MSP430 counterparts help with the more CCS specific questions.

1. I'm not entirely sure the difference, someone from MSP430 can easily explain to us.
2. This is a limitation of CCS6. In a nutshell the file sizes in CCS6 are limited because of a legacy method of licensing and file management. Easiest way to fix this is to update to a newer CCS (Highly recommended) or try a license from here: http://software-dl.ti.com/ccs/esd/documents/ccs_downloads.html#free-license-for-older-versions
3. Probably related to (2).
4. The existing software is designed to be used with the GUI as most customers will be doing so. Using the codebase and CCS, I imagine the code could be modified to run standalone.
5. I am not familiar with any standalone (or implied) instructions, could you show me?
6. Running the project in debug mode in CCS downloads everything needed to the board. Once flashed you can close CCS and use the GUI. The programming will stick around through a power cycle.
7. Likely you were not able to program the board so the GUI cannot read the EVM voltage and is throwing an error.
8. The launchpad is connecting but the code isn't there so it's only partially connected. When properly connected the GUI will list the EVM there instead of just a generic launchpad. 
9. See (2).
10. The code is for the H version.

The GUI is needed at the moment because the code on the EVM needs several commands and communication from the GUI.

Regards,

-Adam

Adam, Thank you.  Your answers definitely shorten my list of questions.

Here are the remaining questions if someone from MSP430 would step in to help...

1) would like a brief explanation of active-debug vs. active-release compilation.  I am thinking active-release loads a "standard" version with no debugger "hooks".  That way when you reset the processor the code simply runs and you don't need an environment to operate the code.  Is this correct?

2) The example TI code active-release build chokes because many of the include files cannot be opened.  I went into the code and changed all the include files to the full pathname until the errors went away.  This is not a clean solution.  Is there a "quick" way to do this? 

Based on Adam's answers the example code must run with the GUI - I am still not sure whether I should compile active-release or active-debug.  NOTE: a later version of CCS does compile without the code size restriction.  So this seems like the way to go. 

Also based on Adam's answers I will have to play around with the board a little bit this week to make sure the code is downloaded to the board, to see if the voltage error in the GUI goes away.  

Ed,

Glad to help. I will forward your post to the MSP430 team for the remaining questions.

The post will stay in this location but internal to our system the post will be directed to MSP430's attention.

Regards,

-Adam

Hi Ed,

the main probable difference between the debug and release should be the missing debug symbols in the release version.

The question from me would be, how did you generate the release version?

As far as I understand the demo you're talking about, it is not possible to operate it without the GUI unfortunately. The other point about the debug / release relation, when looking at debug configuration in the properties window, and MSP430 Compiler settings, you can get the view and summary of the flags set. Please see the attached screen shot. This would be the first point to look at, when trying to compare the configurations of debug and release. Though, as already stated, the demo code is not intended to work without the guy, thus I don't think it makes sense trying to get a release version of it.

Best regards

Peter

Hi Peter, 

Thanks for looking into this.  I am used to working with another embedded processor, which has something like a debug compile and a release compile, so my question about debug/release comes from this background...  With the other compiler, when I compile in debug mode, the code WILL NOT run without the compiler's debug environment.  In this mode I can set breakpoints, look at registers and fix my errors.  When I compile in release mode with the other compiler, then when the processor comes out of reset, it simply starts the code (and I cannot debug it).  When I compile in release mode, it is assumed that I fixed all my errors and the code is ready to rock. 

So I am wondering if the MSP430 compiler works the same way.  

In a way it is a moot point, because the example TI code MUST run with the GUI unless it is reconfigured. But for me it is not a moot point.

Bottom line, for me I am trying to get to my own BLDC code that will run with the MSP430 and the DRV8304.  

With the MSP430 compiler, when I right click on the project, I get the option of compiling either debug or release....next to the project it says in parenthesis (active-debug) or (active-release)

Am I on the right track, or should my understanding be different?  

Ed,

Debug and Release are just project configuration names.  They are the two configurations that a new project comes with.  Initially they are the same.  What people can do is set different build options in them.  You can also include or exclude project files from a configuration (these would be shown as greyed out in the project window).  Traditionally, the Debug configuration would use low or no compiler optimization, while the Release configuration would be using full or high optimization.

Regards,

David

Hi Ed,

could you please let me know, whether there is still something we could do for you on this?

Many thanks in advance,

Best regards

Peter

Hello Peter, 

I am over the hurdle on getting some cursory code running.  I had to overcome a few significant issues that you could check into...

The DRV8304 data sheet indicates the following:  7.3.1.1.2 3x PWM Mode (PWM_MODE = 01b or MODE Pin = 47 kΩ to AGND)

The schematic for the DRV8304HEVM entitled MD008E2(002)_Sch.PDF shows a 47k pull down to ground on the MODE pin.  This led me to set up my commutation table according to mode = 3x PWM.

When I powered up, it did not work.  After doing some experiments to root cause the issue, I learned that the EVM was definitely in mode = Synchronous 1x PWM Mode.

I re-did my commutation table for the 1x mode and it works.  Something significant is not right about EVM system.  Not sure whether it is in the specs or the board.  

Next item:  the DRV8304 data sheet does not show anywhere that I can see the voltage that corresponds to levels for the 4 multilevel pins.  This would be very helpful for both design and debug.  

Next item:  Figure 4 in the DVR8304HEVM user manual is missing Hall B, and a couple other items that are listed later in the document.  I wound up using the schematic for the EVM which is correct on these pin mappings.

Next item:  Table 1 in the DVR8304HEVM user manual assigns P2.2 for both J4 pin 6 and pin 18.  J4 Pin 18 actually is assigned to P2.3 for the HEVM.