The message you received just stored an internal component to let Creator keep track of your version. Nothing has been changed so far in your program and: there is no issue with an UDB-shift afaik.
When your debugging session runs el wracko, I'd suggest you to set (Project->Build Settings->Compiler...) Optimization Level to "None" and try again.
Optimization level is alredy on none. I wonder if it has to do with this paragraph in the release notes (attached image). Although this paragraph appears to suggest I only need worry if I have "mixed clock enable modes" which I don't *think* I have...
Anyway, I've just tracked down the conytrol file help topic and am reading.
rnexp.jpg 49.9 K
Well I got as far as adding a control file, but have no idea how to populate it! I'm stuck.
Looks like I'm continuing with Creator 3.1.
As long as you do not have any self-configured UDBs using VeriLog or Datapath editor this message doesn't apply to your project.
At first, to keep things running: File a MyCase and submit your not-running-project together with the needed informations for external connections, board used etc.
When you can post the very same information here in the forum, someone else can have a look at. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
This time, on returning to Creator 3.1, my interrupts were no longer functioning (or at least, the code hung in the same way it did before I got the interrupts working properly in the first place). Thankfully, there was a backup file to fall back on! I was biting my nails for a bit there - I've *just* got sustained 18 Mbps SD card reading working, and would hate to lose it!
Perhaps I'm doing something I shouldn't be that the updated creator studio doesn't work with, but it's beyond my capabilities to see where the problem is coming from at the moment. The fact that my ISRs seemed to stop working this time has completely baffled me - if the circuit wasn't in a PSoC, I'd assume a loose connection on the breadboard in the midst of my control logic!
Anyway, unless there are suggestions here as to what might have gone wrong with a UDB editor design for an SPI interface using the Count7 component and a state machine along with the datapath, then connected directly to an RX ISR as well as connected to both RX and TX DMAs (with their own ISRs) in a schematic, I'm sticking with Creator 3.1 and missing out on any advances made in Creator 3.2!
I've attached a file here - will file a MyCase afterwards.
I'm using the CY8CKIT-059, and have reduced the project to my SD card interface alone, and got rid of all my other experiments.
Pins: 3 = SD_CS, 3 = SD_MISO, 3 = SD_MOSI and 3 = SD_SCLK. Assuming VDDIO is set to 3.3 V (I removed R15 and tied a 3.3V regulator to VDDIO to do this), the PSoC can connect directly to the SD card.
I've tested the attached project, and when compiled in Creator 3.1 it works fine, but in Creator 3.2 it does nothing! main.c should open a file on the (FAT16 / FAT32 formatted) SD card, write 16000 bytes and close then report time taken. Next, open the same file to read the 16000 bytes and verify the data, then report time taken for read. It then repeats these steps with another 16000 byte file after enabling the DMA mode. Output is to "test.txt" on the SD card, reporting results of tests.
Well I can't select a device in the MyCase interface, because Cypress is apparently offline in that window only! I'll try again later. In the meantime I think I'll uninstall Creator 3.2 again. I've done all the testing I can do.
You don't need to select a device when creating a MyCase, just say you do not know it and continue.
There are a bunch of warnings in your project I (personally) would not put aside.
Combinatorial loop: I would suggest to replace your 2 NORs with an SR-FF component and a NOT-gate.
and last which will be the reason for the project not working increase the heap size (system tab in .cydwr-file) to something like 0x200
See attached (except the SR-FF9
Wait.. You're not telling me that Creator 3.2 has defaulted my heap size to a smaller value again are you? I was caught out by something very similar last year! I will reinstall and have another look.
As to the combinatorial loop - that is my preferred method in this case - it works beautifully, and doesn't give me a clock-cycle delay. I did replace it with an SR flip flop early on in the design, but that was when I was clutching at straws to fix what turned out to be my forgetting to clear a pending interrupt. Is there a particular reason why a combinatorial loop to implement an SR latch would upset the surrounding logic?
Well it's not a heap size problem (although good point- I never increased the heap size when I created the ComponentTest project!). I tried increasing the heap, AND tried compiling your modified version, and neither worked. I'm not at all convinced it's the combinatorial loop either - they've worked fine in a few designs, so unless Creator 3.2 has a particular issue with combinatorial loops, that's not it. The Setup time violations are unavoidable as far as I can see - but also ignoreable by my understanding because I set the clock divider in software to a rate that works. I'm at a loss again!
Thanks very much for having a look though :)
I've just tried the SR-FF approach again. It doesn't add an extra cycle like I thought (cue more staring at schematic for me), but it also doesn't fix things in Creator 3.2 despite still working in Creator 3.1. For the sake of having one less warning, I'll stick with the SR flip flop though.
On a side note - While writing this I've realised why the SR flip flop doesn't add a cycle - the cycle is already there in the state machine implementation.