Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kb1gtt

Pages: 1 2 [3] 4 5
The datasheet wants me to look at S0SPCCR for the SPI clock settings. The example code I'm looking at uses SSPCPSR_X to set the clock, but appears to be using SSP not SPI registers. It appears that SSP can be used for SPI and I'm not sure if this type of SSP/SPI can be used with my device or not. Is there a way to get the simulator and device to work with the dedicated SPI hardware?

Under LPC23XX.h I see this.

  #define RTC_BLOCK                      0xe0024000
  #define LEGACY_GPIO_BLOCK              0xe0028000
  #define PIN_CONNECT_BLOCK              0xe002c000

I would guess I can add #define S0SPCCR 0xE002000C, but I don't think I'd get it in the simulator. Can I add this to the simulator?

Or even better what about adding 0xE002 0000, then the +000C thing more like the normal practice in other parts of this code.

So it would appear that under FIOSET when the datasheet notes, "Writing 0s has no effect." What they really mean is that writing a 1, will cause the port to be pulled high, and writing a 0 will cause the port to not be driven by the high side drive. Disconnecting the high side drive is a lot different than no effect. Once I cleared both the FIOSET and FIOCLR, I was free to control the port via FIO0PIN. Now it's off to debugging SPI clocking.

I noticed FIOSET and FIOCLR are both set. Perhaps this is where things get buggered... Here's a snap shot of my watch window, just after it ran the CS_CLR_PORT = CS0_LINE command.
Code: [Select]
- [0x0] {FIODIR=0x00600040 res1=0x00539f6c FIOMASK=0x00000000 ...} stLPC23XX_FAST_GPIO
FIODIR 0x00600040 unsigned long
+ res1 0x00539f6c unsigned long [3]
FIOMASK 0x00000000 unsigned long
FIOPIN 0xffdfffff unsigned long
FIOSET 0x00400042 unsigned long
FIOCLR 0x00000040 unsigned long
I notice FIOPIN is a 1. I also read that "Writing 0s has no effect" on FIOSET. Perhaps I have to write a 0 to this such that FIOCLR can drive it low? I'm a bit baffled about why this isn't working.

Great the simulator is working and now several tests match what I'm seeing on the target and the simulator. Having it working helped me debug my code that simply lists bits to the screen, which allowed me to verify that bits are internally being set correctly.

I'm not seeing what I expect to see on the target pins. I have verified several bits via LCD. However, I can't seem to get P0.6 SSEL1, to go low. It has a 33K external pull up to 3.3v. I've tried enabling/disabling internal pulls, I've tried it as SSEL and GPIO. I don't appear to have enough drive to change the voltage at all. I would say I most likely don't have something configured correctly, so here's some code snippets. From "myfirsttask" which runs 2 seconds after boot, then each second after,

Code: [Select]
#define WHO_AM_I 0x0F //memory location 0x0F should read as 0x3A
CS_CLR_PORT = CS0_LINE;  //ulChipSelectLine; // assert SS low before starting
SSPDR_X = WHO_AM_I; //request this reg
while (SSPSR_X & (SSP_BSY | SSP_RNE)) { // wait for transfer to complete and clear rx buffer
     volatile unsigned long ulDummy = SSPDR_X;
//CS_SET_PORT = CS0_LINE;//ulChipSelectLine;
And from the included header file.
Code: [Select]
static void fnConfigSPI_jah(void)//unsigned char ucSpeed)
    POWER_UP(PCSPI);                                                   // {10} power up the SSP used
//clock  PCLK_SEL0 select PCLK_SPI
//currently it's got a clock rate, I'll deal with specifics later.
//pin sel / mode

    SSPCR1_X = 0;                                                        // ensure disabled (master mode)
    SSPCPSR_X = 8;                                                       // set clock prescaler (even prescale 2..254)

//    switch (ucSpeed) {
//    case MAX_SPI:                                                        // set maximum possible SPI speed
        SSPCR0_X = (FRS_FREESCALE_SPI | DSS_8_BIT | (0 << SSP_SCR_SHIFT)); // set exact frequency and mode
//     break;

//    case SPI_2MEG:
//        SSPCR0_X = (FRS_FREESCALE_SPI | DSS_8_BIT | ((((SSP_CLOCK/2 + 2000000/2)/2000000) - 1) << SSP_SCR_SHIFT)); // set exact frequency and mode
//     break;

//    case SPI_SLAVE:
//     return;
//    }
    SSPCR1_X = SSP_SSE;                                                  // enable
Also from app_hw_lpc23xx.h I added to this command, such that PO_6 is SSEL. This command comes and goes with my testing/debugging.
Code: [Select]
#define CONFIGURE_SPI_PINS()        PINSEL0 |= (PINSEL0_P0_8_MISO1 | PINSEL0_P0_9_MOSI1 | PINSEL0_P0_7_SCK1 | PINSEL0_P0_6_SSEL1); // MOSI, MISO and SCK pins enabled - on SSP1

Because I've commented out //CS_SET_PORT, I expect it to pull PO.6 low and keep it there. The simulator currently shows this a lower case p, and if I comment out the SSEL thing, it shows as a O, or 1 based which CS_SET_PORT I comment out. However, it just stays there at 3.3v, doesn't budge a bit, I don't see any bumps on the scope.

Are there any suggestions or pointers? When configured for SSEL, I might guess this is automatic, such that I can't drive it high or low manually. This would make since why I can't git it to go high or low. When configured as GPIO, I believe the direction is set correctly, but no dice.

I think I may have found another memory mapping issue. I'm trying to use the UEXT connector on the LPC23478-stk. When I do this code
Code: [Select]
PINMODE0 |= PINMODE_PULLDOWN_6;I get this result in the watch window, also the real hardware doesn't seem strong enough to pull down the bit, so it would appear the pull down is not activated.
Code: [Select]
PINMODE0 0x00000000 unsigned long
PINMODE5 0x00003000 unsigned long
It appears it did those bits to the 5, not the 0 mode.

I'm posting this partly to share, partly to remind myself if I'm looking for a reminder about what happened on the above broken hex issue. The issue was sourced when I created my own task. The make file didn't include my-first-task.c and was producing a cs-make error, even though the output window reported success while compiling. I noticed the error message failed relative to and undefined my-first-task.

So I changed make_uTaskerV1.4_GNU_LPC23XX to read like this.
Code: [Select]
# All objects (Hardware, application, uTasker, stack)
OBJS = Build/my-first-task.o Build/application.o blah blah

# Application files
#added by jah
Build/my-first-task.o: ../my-first-task.c $(DEPENDS) ../application_lcd.h ../config.h
$(CC) $(C_FLAGS) $(INC) $(OPTS) ../my-first-task.c -o Build/my-first-task.o
#end added by jah

Build/application.o: ../application.c blah blah
It now again compiles the .hex file, and I'm back to debugging my code. Because it fails, but Visual Studio thinks is passed, you'll have to build clean each time you change the make file to get this to compile.

It might be handy to add a note in section 5 of the users guide about the make file.

I just ran into a bit of a bugger. Flash magic was pointing to programming uTaskerV1.4.hex which  hasn't  been modified since the 15th. It appears that for some reason Visual Studio changed, and is compiling uTaskerBM.hex. I guess I'll have to go look over my configs. This BM version doesn't run on my proto board. However the simulator is working just fine. Could this be part of the recently modified simLPC23XX.h?

I see config.h is still set to #define OLIMEX_LPC2378_STK. A quick look down the project properties didn't cause anything to jump out at me. I'm not sure why the hex file changed, and it's time again to head out for the bump and grind. So until later this evening, I'll ponder what is going on.

So it appears that great things happen to those that that can read....

I just re-found the uTaskerV1.4_user_guide.pdf section 5 about creating your own task. I followed those great instructions then copied my code into this new task and the rebooting issue is no longer. I'm currently learning more about how tasks are handled, and following the examples, ect.

Great, the 200hz works well, and 100hz has flicker. At 30% PWM it still draws 172ma. I haven't tried the other PWM rates yet.

I was digging into the LCD PWM in an attempt to resolve a problem I'm seeing. Unfortunately dimming the LCD didn't fix the problem, so perhaps this problem is sourced from somewhere else. The problem happens every 6.5 seconds when the proto board appears to reboot. The screen goes blank briefly and it appears to start the code again.

I had assumed this was due to the my supply being limited to 200ma via ARM-USB-OCD programmer device, and that the device may have been smart enough to notice I was drawing 203 ma when the LCD was on. Now I'm a fair bit under the max rating, and I'm still seeing this issue. I'm beginning to wonder if it might be a watch dog issue.

Are there any suggested areas where I should look to figure out why it might be rebooting every 6.5 seconds or so? My multimeter is telling me the min voltage drops to 4.77v while the normal voltage reads as 4.80v. So I don't think it's a power supply issue at this point.

The correction (which I tested with all 6 channels) is:
Great and thanks. This now works both in the simulator/watch window, as well as the proto board. Here are what I measured for PWM and current draw.

when at 100%, it measures 203ma, and is very bright
when at     0%, it measures 159ma, and is very dim
when at    20% it measures 160ma, and is very dim
when at   30%, it measures 172ma, and is reasonably bright
when at   35%, it measures 196ma, and is very bright, but not as much as

So the range for LCD appears to be around 25% to 35%, with 30% being good enough for indoor applications.

I guess it's now time to get back to the SPI stuff.

Great, and again you were very helpful.

It currently shows PWM in the watch window, and allows me to verify the different bits. Lots of things look good, but I'm still not getting the PWM I expect. Perhaps my issue is that I don't fully understand the PWM_PERCENT call.

I used the the original LPC23XX.c and LPC23XX.h files then added the PWM sections of the files you sent along separately. I used the newer simLPC23XX.h with out compile problems. It now compiles and appears to work.

I don't know exactly how to use the temp_parameters.ucGLCDContrastPWM noted above, so I changed that line to be like this.
Code: [Select]
timer_setup.pwm_value   = _PWM_PERCENT(50,timer_setup.timer_value);//temp_pars->temp_parameters.ucGLCDContrastPWM, timer_setup.timer_value); // contrast as PWM valueI was aiming for a hard coded 50% PWM. I then called this function from in application.c under fnApplication. I'm probably calling this far more often than is required.

From the watch window I see

      PWMIR   0x00000000   unsigned long
      PWMTCR   0x00000009   unsigned long
      PWMTC   0x00000000   unsigned long
      PWMPR   0x00000000   unsigned long
      PWMPC   0x00000000   unsigned long
      PWMMCR   0x00000002   unsigned long
      PWMMR0   0x00000708   unsigned long
      PWMMR1   0x00000000   unsigned long
      PWMMR2   0x00000000   unsigned long
      PWMMR3   0x00000000   unsigned long
      PWMCCR   0x00000000   unsigned long
      PWMCR0   0x00000000   unsigned long
      PWMCR1   0x00000000   unsigned long
      PWMCR2   0x00000000   unsigned long
      PWMCR3   0x00000000   unsigned long
      ulRes0   0x00000000   unsigned long
      PWMMR4   0x00000000   unsigned long
      PWMMR5   0x00000000   unsigned long
      PWMMR6   0x00000000   unsigned long
      PWMPCR   0x00004000   unsigned long
      PWMLER   0x00000041   unsigned long
+      ulRes1   0x0054ad5c   unsigned long [7]
      PWMCTCR   0x00000000   unsigned long

These appear to me like channel 6 is set to PWM output, I believe that PWMMR6 indicates it's set to a 0% duty. This makes since as the LCD is dark, which leads me to believe that I'm not using PWM_PERCENT correctly. I've tried a handful of values large, small, hex, ect. PWMMR6 keeps coming back as 0. Perhaps I buggered something when I modified the LPC23XX files, I'm not sure. I searched for PWM_PERCENT to try and verify what it's expecting, but I didn't manage to find it. Just a define and a couple places where it's called.

Am I using PWM_PERCENT correctly? Is PWMMR indicating the duty?

I stepped away from this for a bit and I'm getting back into it again. I'm still having trouble figuring out how to see contents of registers that do not appear to be in LCP23XX.h. I'm looking to set the PWM 1.6 for the LCD such that I can dim the display on my LPC2378-STK dev board. Registers like PCONP and PINSEL3 work great. I wrote to them, and verified they work via the watch window. Also the simulator notes that pin is now PWM1.6, so it's looking great. However, I need to work with the below noted registers and I don't know how to set or verify bits of those registers.

From the UM10211 data sheet, I'm looking at PWM1TCR found on page 549, and PWM1MCR found on 550. The don't appear to be in the LPC23XX.h file, I've also looked under the timer section, and no dice. They start at 0xE001 8000 and it appears that UART_BLOCK_1 is 0xE001 0000, so I added the lines noted in the above thread to the watch window. This did not work, it would appear they are not supported in the dirver.c file. Right now it would appear that the PWM for this chip is not currently developed and falls outside of the memory range managed by the simulator. I may be wrong with that. My next attempt was to make it display on the physical LCD. However, I'm having some trouble getting that to work as well.

Is there a recommended way to view the contents of registers like PWM1TCR - 0xE001 8004 and PWM1MR - 0xE001 8048 ?

I'm now looking at the registers and I think I found what you meant by there isn't a hardware driver for the 23XX chip. It appears it isn't defined in the LPC23XX.h or simLPC23XX.h. So I changed simLPC23XX.h to be like this.
Code: [Select]
unsigned long TER;
unsigned long PWM1MR; // ADDED BY JAH
unsigned long PWM1PCR; // added by jah
And LPC23XX.h looks like this.
Code: [Select]
#define U1TER                            *(volatile unsigned long*)(UART_BLOCK_1 + 0x30) // Transmit Enable Register
#define PWM1MR *(unsigned long*)(UART_BLOCK_1 + 0x8048) // PWM mod by JAH
#define PWM1PCR *(unsigned long*)(UART_BLOCK_1 + 0x804C) // PWM mod by JAH
Then I added this to application.c
Code: [Select]
PINSEL3 |=  1<<21;
PCONP |= 1<<6;
PCLKSEL0 |= 1<<12;
PWM1MR = 0xffffffff;
When I pause the debugger, ucLPC23xx.ucSimUart1 shows me both the PWM1MR and PWM1PCR as 0x00000000. That makes sense for PWM1PCR because it's default at boot is 0, and I appears utasker isn't changing that to something different. However, I wrote F's to PWM1MR so I expected to read back at a different value. Can I add registers like I have to the simulation, or is there other work that has to happen behind the scenes. Perhaps I need to add something to simLPC23XX.c?

I see it now, I hadn't noticed that when I ran the simulator, the debugger popped up a watch window. I was thinking the watch window was the simulator. I see it now and I can look at these nitty gritties.

Thanks for the help.

I believe I'm having some trouble pausing the simulator. Right now when I select, then drag the text ucLPC23xx.ucSCM from LPC23XX.h, I get a circle with a line through it, indicating that this type of drag and drop isn't allowed by windows. I tried inserting a break point in the code then dragging and dropping, I also tried hitting the pause (Break All) button, but no dice.  I didn't see a pause command in the simulator pull downs.

Pages: 1 2 [3] 4 5